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^ , Abstract 

Recent research on mutual exclusion for shared-memory systems has focused on local spin 
qq ■ algorithms. Performance is measured using the remote memory references (RMRs) metric. As 

common in recent literature, we consider a standard asynchronous shared memory model with 
N processes, which allows atomic read, write and compare-and-swap (short: CAS) operations. 
In such a model, the asymptotically tight upper and lower bounds on the number of RMRs 
U 1 per passage through the Critical Section is 8 (log TV) for the optimal deterministic algorithms [271 

[7J. Recently, several randomized algorithms have been devised that break the 17 (log AT) barrier 
and need only o(log N) RMRs per passage in expectation [16l[lTJ[8]. In this paper we present the 
first randomized abortable mutual exclusion algorithm that achieves a sub-logarithmic expected 
RMR complexity. More precisely, against a weak adversary (which can make scheduling decisions 
based on the entire past history, but not the latest coin-flips of each process) every process needs 
an expected number of 0(logiV/loglog N) RMRs to enter end exit the critical section. If a 
process receives an abort-signal, it can abort an attempt to enter the critical section within a 
finite number of its own steps and by incurring 0(log A/loglog N) RMRs. 



oo; 

^ ; 1 Introduction 



Mutual exclusion, introduced by Dijkstra [TT], is a fundamental and well studied problem. A mutual 
exclusion object (or lock) allows processes to synchronize access to a shared resource. Each process 
obtains a lock through a capture protocol but at any time, at most one process can own the lock. 
A process is said to own a lock if it participates in a "capture" protocol designed for the object, 
and completes it. The owner of the lock can access the shared resource, while all other processes 
wait in their capture protocol for the owner to "release" the lock. The owner of a lock can execute 
a release protocol which frees up the lock. The capture protocol and release protocol are often 
denoted entry and exit section, and a process that owns the lock is in the critical section. 

In this paper, we consider the standard cache- coherent (CC) shared model with N processes 
that supports atomic read, write, and compare-and-swap (short: CAS) operations. In this model, 
all shared registers are stored in globally accessible shared memory. In addition, each process has 
a local cache and a cache protocol ensures coherency. A Remote Memory Reference (short: RMR) 
is a shared memory access of a register that cannot be resolved locally (i.e., a cache miss). Mutual 
exclusion algorithms require processes to busy-wait, so the traditional step complexity measure, 
which counts the number of shared memory accesses, is not useful. 
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Early mutual exclusion locks were designed for uniprocessor systems that supported multitask- 
ing and time-sharing. A comprehensive survey of these locking algorithms is presented in |25j . One 
of the biggest shortcomings of these early locking algorithms is that they did not take into account 
an important hardware technology trend - the steadily growing gap between high processor speeds 
and the low speed /bandwidth of the processor- memory interconnect [9] . A memory access that tra- 
verses the processor-to- memory interconnect, called a remote memory reference, takes much more 
time than a local memory access. 

Recent research [5j [24], [21 [231 El El EH EH [22] on mutual exclusion algorithms therefore focusses 
on minimizing the number of remote memory references (RMR). The maximum number of RMRs 
that any process requires (in any execution) to capture and release a lock is called the RMR 
complexity of the mutual exclusion algorithm. RMR complexity is the metric used to analyze the 
efficiency of mutual exclusion algorithms, as opposed to the traditional metric of counting steps 
taken by a process (step complexity). Step complexity is problematic, since for mutual exclusion 
algorithms, a process may perform an unbounded number of memory accesses (each considered a 
step) while busy- waiting for another process to release the lock pp. 

Algorithms that perform all busy-waiting by repeatedly reading locally accessible shared vari- 
ables, achieve bounded RMR complexity and have practical performance benefits [5]. Such algo- 
rithms are termed local spin algorithms. A comprehensive survey of these algorithms is presented 
in [4]. Yang and Anderson presented the first 0(logN) RMRs mutual exclusion algorithm |27j 
using only reads and writes. Anderson and Kim [2 J conjectured that this was optimal, and the 
conjecture was proved by Attiya, Hendler, and Woelfel [7]. 

Local spin mutual exclusion locks do not meet a critical demand of many systems [26] , Specif- 
ically, the locks employed in database systems and in real time systems must support a "timeout" 
capability which allows a process that waits "too long" to abort its attempt to acquire the lock. 
The ability of a thread to abort its lock attempt is crucial in data base systems; for instance in 
Oracle's Parallel Server and IBM's DB2, this ability serves the dual purpose of recovering from 
transaction deadlock and tolerating preemption of the thread that holds the lock [26J. In real 
time systems, the abort capability can be used to avoid overshooting a deadline. Locks that allow 
a process to abort its attempt to acquire the lock are called abortable locks. Jayanti presented 
an efficient deterministic abortable lock [21] with worst-case 0(log N) RMR complexity, which is 
optimal for deterministic algorithms. 

In this paper we present the first randomized abortable mutual exclusion algorithm that achieves 
a sub-logarithmic RMR complexity. Due to the inherent asynchrony in the system, the RMRs 
incurred by a process during a lock capture and release depend on how the steps of all the processes 
in the system were scheduled one after the other. Therefore, the maximum RMRs incurred by any 
process during any lock attempt are determined by the "worst" schedule that makes some process 
incur a large number of RMRs. To analyze the RMR complexity of lock algorithms, an adversarial 
scheduler called the adversary is defined. The lower bound of Q(logN) in [7] for mutual exclusion 
algorithms that use only reads and writes holds for deterministic algorithms where the adversary 
knows all processes' future steps. The lower bound does not hold for randomized algorithms where 
processes flip coins to determine their next steps. Randomized algorithms limit the power of an 
adversary since the adversary cannot know the result of future coin flips. Adversaries of varying 
powers have been defined. The most common ones are the oblivious, the weak, and the adaptive 
adversary [6j. An oblivious adversary makes all scheduling decisions in advance, before any process 
flips a coin. This model corresponds to a system, where the coin flips made by processes have no 
influence on the scheduling. A more realistic model is the weak adversary, who sees the coin flip of 
a process not before that process has taken a step following that coin flip. The adaptive adversary 
models the strongest adversary with reasonable powers, and it can see every coin flip as it appears, 



2 



and can use that knowledge for any future scheduling decisions. Hendler and Woelfel [16J and 
later Giakkoupis and Woelfel [12] established a tight bound of (log N/ log log N) expected RMR 
complexity for randomized mutual exclusion against the adaptive adversary. Recently Bender 
and Gilbert [8] presented a randomized lock that has amortized C(log 2 log N) expected RMR 
complexity against the oblivious adversary. Unfortunately, this algorithm is not strictly deadlock- 
free (processes may deadlock with small probability so deadlock has to be expected in a long 
execution). Our randomized abortable mutual exclusion algorithm is deadlock- free, works against 
the weak adversary and achieves the same epected RMR complexity as the algorithm by Hendler 
and Woelfel, namely O (log N/ log log N) expected RMR complexity against the weak adversary. 

The randomized algorithm we present uses CAS objects and read-write registers. Golab, Hadzi- 
lacos, Hendler, and Woelfel [14j (see also [13]) presented an C(l)-RMRs implementation of a CAS 
object using only read-write registers. Moreover, they proved that one can simulate any deter- 
ministic shared memory algorithm that uses reads, writes, and conditional operations (such as CAS 
operations), with a deterministic algorithm that uses only reads and writes, with only a constant 
increase in the RMR complexity. Recently in [15], Golab, Higham and Woelfel demonstrated that 
using linearizable implemented objects in place of atomic objects in randomized algorithms allows 
the adversary to change the probability distribution of results. Therefore, in order to safely use 
implemented objects in place of atomic ones in randomized algorithms, it is not enough to simply 
show that the implemented objects are linearizable. Also in [15], it is proved that there exists no 
general correctness condition for the weak adversary, and that the weak adversary can gain addi- 
tional power depending on the linearizable implementation of the object. Therefore, in this paper 
we assume that CAS operations are atomic. 

Abortable Mutual Exclusion. We formalize the notion of an abortable lock by specifying 
two methods, lock() and release (), that processes can use to capture and release the lock, 
respectively. The model assumes that a process may receive a signal to abort at any time during its 
lockQ call. If that happens, and only then, the process may fail to capture the lock, in which case 
method lock() returns value _L. Otherwise the process captures the lock, and method lockQ 
returns a non-_L value, and the lockQ call is deemed successful. Note that a lockQ call may 
succeed even if the process receives a signal to abort during a lockQ call. 

Code executed by a process after a successful lockQ method call and before a subsequent 
release Q invocation is defined to be its Critical Section. If a process executes a successful lock Q 
call, then the process's passage is defined to be the lockQ call, and the subsequent Critical Section 
and release Q call, in that order. If a process executes an unsuccessful lockQ call, then it does 
not execute the Critical Section or a release Q call, and the process's passage is just the lockQ 
call. Code executed by a process outside of any passage is defined to be its Remainder Section. 

The abort-way is defined to be the steps taken by a process during a passage that begins when 
the process receives a signal to abort and ends when the process returns to its Remainder Section. 
Since it makes little sense to have an abort capability where processes have to wait for other 
processes, the abort-way is required to be bounded wait-free (i.e., processes execute the abort- 
way in a bounded number of their own steps). This property is known as bounded abort. Other 
properties are defined as follows. Mutual Exclusion: At any time there is at most one process in the 
Critical Section; Deadlock Freedom: If all processes in the system take enough steps, then at least 
one of them will return from its lock Q call; Starvation Freedom: If all processes in the system take 
enough steps, then every process will return from its lockQ call. The abortable mutual exclusion 
problem is to implement an object that provides methods lockQ and release Q such that it that 
satisfies mutual exclusion, deadlock freedom, and bounded abort. 
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1.1 Model 



Our model of computation, the asynchronous shared-memory model [20J with N processes which 
communicate by executing operations on shared objects. Every process executes its program by 
taking steps, and does not fail. A step is defined to be the execution of all local computations 
followed by an operation on a shared object. We consider a system that supports atomic read- write 
registers and CAS() objects. 

A read-write register R stores a value from some set and supports two atomic operations 
i?.Read() and i?.Write(). Operation i?.Read() returns the value of the register and leaves its 
content unchanged, and operation R. Write (u) writes the value v into the register and returns 
nothing. A CAS object O stores a value from some set and supports two atomic operations O.CASO 
and O.ReadQ. Operation O.ReadQ returns the value stored in O. Operation O.CAS (exp, new) 
takes two arguments exp and new and attempts to change the value of O from exp to new. If the 
value of O equals exp then the operation O.CAS (exp, new) succeeds, and the value of O is changed 
from exp to new, and true is returned. Otherwise, the operation fails, and the value of O remains 
unchanged and false is returned. 

In addition, a process can execute local coin flip operations that returns an integer value dis- 
tributed uniformly at random from an arbitrary finite set of integers. The scheduling, generated by 
the adversary, can depend on the random values generated by the processes. We assume the weak 
adversary model (see for example [6]) that decides at each point in time the process that takes the 
next step. In order to make this decision, it can take all preceding events into account, except the 
results of the most recent coin flips by processes that are yet to execute a shared memory operation 
after the coin flip. 

As mentioned earlier, we consider the cache- coherent (CC) model where each processor has a 
private cache in which it maintains local copies of shared objects that it accesses. The private 
cache is logically situated "closer" to the processor than the shared memory, and therefore it can 
be accessed for free. The shared memory is an external memory accessible to all processors, and is 
considered remote to all processors. We assume that a hardware protocol ensures cache consistency 
(i.e., that all copies of the same object in different caches are valid and consistent). A memory 
access to a shared object that requires access to remote memory is called a remote memory reference 
(RMR). The RMR complexity of a algorithm is the maximum number of RMRs that a process can 
incur during any execution of the algorithm. 

1.2 Results 

We present several building blocks for our algorithm in Section [2j In Sections [3] and [4] we give 
an overview of the randomized mutual exclusion algorithm. Our results are summarized by the 
following theorem. 

Theorem 1.1. There exists a starvation-free randomized abortable N process lock against the weak 
adversary, where a process incurs O (log N/ log log N) RMRs in expectation per passage. The lock 
requires O(N) CAS objects and read-write registers 

2 Building Blocks 

A Randomized CAS Counter. A CAS counter object with parameter k E Z + complements a 
CAS object by supporting an additional inc() operation (apart from CAS() and Read() operations) 
that increments the object's value. The object takes values in {0, . . . , k}, and initially the object's 
value is 0. Operation inc() takes no arguments, and if the value of the object is in {0, . . . , k — 1}, 
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then the operation increments the value and returns the previous value. Otherwise, the value of 
the object is unchanged and the integer k is returned. We will use such an object for k = 2 to 
assign three distinct roles to processes. 

Our implementation of the inc() operation needs only O(l) RMRs in expectation. A determin- 
istic implementation of a CAS counter for k = 2 and constant worst-case RMR complexity does not 
exist: Replacing our randomized CAS counter with a deterministic one that has worst-case RMR 
complexity T yields a deterministic abortable mutual exclusion algorithm with worst-case RMR 
complexity 0{T ■ log N/ log log N) . From the lower bound for deterministic mutual exclusion by 
Attiya etal. [7], such an algorithm does not exist, unless T = f2 (log log A)0 

In Appendix[Al we describe a randomized CAS counter, called RCAScounterfc, where the inc() 
method is allowed to fail. The idea is, that to increase the value of the object, a process randomly 
guesses its current value, v, and then executes a CAS(v,v + 1) operation. An adaptive adversary 
could intervene between the steps involving the random guess and the subsequent CAS operation, 
thereby affecting the failure probability of an inc ( ) method call, but a weak adversary cannot do 
so. 

Lemma 2.1. Object RCAScounterfc is a randomized wait-free linearizable CAS Counter, where the 
probability that an inc() method call fails is against the weak adversary. Each of the methods 
of RCAScounterfc has 0(1) step complexity. 

A Single-Fast-Multi-Slow Universal Construction. A universal construction object pro- 
vides a linearizable concurrent implementation of any object with a sequential specification that 
can be given by deterministic code. In Appendix[B]we devise a universal construction object SFM- 
SUnivConst(T) for N processes H which provides two methods, doFast (op) and doSlow(op), to 
perform any operation op on an object of type T. The idea is that doFastQ methods cannot be 
called concurrently, but are executed very fast, i.e., they have 0(1) step complexity. On the other 
hand, doSlowO methods need 0(A) steps. The algorithm is based on a helping mechanism in 
which doSlowO methods help a process that wants to execute a doFastO method. 

Lemma 2.2. Object SFMSUnivConst(T) is a wait-free universal construction that implements an 
object O of type T, for N processes, and an operation op on object O is performed by executing either 
method doFast (op) or doSlow(op) , and no two processes execute method doFast () concurrently. 
Methods doFast () and doSlowO have 0(1) and 0(A) step complexity respectively. 

The Abortable Promotion Array. An object O of type AbortableProArray fc stores a vector 
of k integer pairs. It provides some specialized operations on the vector, such as conditionally 
adding/removing elements, and earmarking a process (associated with an element of the vector) for 
some future activity. Initially the value of O = (O[0], 0[1], . . . , 0[k - 1]) is ((0, _L), . . . , (0, _L)). The 
object supports operations collect (), abort (), promote (), remove () and reset () (see Figure [5] 
in the appendix). Operation collect (X) takes as argument an array X[0 . . . k — 1] of integers, and 
is used to "register" processes into the array. The operation changes 0[i], for alH in {0, . . . , k — 1}, 
to value (REG,X[i]) except if 0[i] is (ABORT, s), for some s £ Z. In the latter case the value of 
0[i] is unchanged. Process i is said to be registered in the array if a collect () operation changes 
0[i] to value (REG, s), for some s£Z. The object also allows processes to "abort" themselves from 

For the DSM model, this also follows from a result by Golab, Hadzilacos, Hendler, and Woelfel [14]. They 
established a super-constant lower bound on the RMR complexity of a deterministic bounded counter that can count 
up to two, and also supports a reset operation. 

2 We use the universal construction object for smaller sets of processes, specifically for sets of size 
O (log N/ log log N) . 
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the array using the operation abort (). Operation abort (i,s) takes as argument the integers i 
and s, where i G {0, . . . , k — 1} and s £ Z. The operation changes 0[i] to value (ABORT, s) and 
returns true, only if 0[i] is not equal to (PRO, s'), for some s' G Z. Otherwise the operation returns 
false. Process i aborts from the array if it executes an abort (z,s) operation that returns true. 
A registered process in the array that has not aborted can be "promoted" using the promote () 
operation. Operation promote () takes no arguments, and changes the value of the element in O 
with the smallest index and that has value (REG, s), for some s G Z, to value (PRO, s), and returns 
(i,s), where i is the index of that element. If there exists no element in O with value (REG,s), 
for some s£Z, then O is unchanged and the value (_L, _L) is returned. Process i is promoted if a 
promote () operation returns (i, s), for some s G Z. Operation reset () resets the entire array to 
its initial state. 

Note that an aborted process in the array, cannot be registered into the array or be promoted, 
until the array is reset. If a process tries to abort itself from the array but finds that it has already 
been promoted, then the abort fails. This ensures that a promoted process takes responsibility for 
some activity that other processes expect of it. 

In the context of our abortable lock, the i-th element of the array stores the current state of 
process with ID i, and a sequence number associated with the state. Operation collect () is used 
to register a set of participating processes into the array. Operation abort (i, s) is executed only 
by process i, to abort from the array. Operation promote () is used to promote an unaborted 
registered process from the array, so that the promoted process can fulfill some future obligation. 

In our abortable lock of Section O we need a wait-free linearizable implementation of type 
AbortableProArray^, where A is the maximum number of processes that can access the object con- 
currently, and we achieve this by using object SFMSUnivConst(AbortableProArray^). We ensure that 
no two processes execute operations collect (), promote (), reset () or remove () concurrently, 
and therefore by we get 0(1) step complexity for these operations by using method doFast(). 
Operation abort () has 0(A) step complexity since it is performed using method doSlowQ, which 
allows processes to call abort ( ) concurrently. 

3 The Tree Based Abortable Lock 

Our abortable lock algorithm is based on an arbitration tree with branching factor approximately 
O (log N/ log log N) . For convenience we assume (w.l.o.g.) that A" = A A_1 for some positive integer 
A, where A" is the maximum number of processes in the system. Then it follows that A = ©(log N / 
log log N). 

As in the algorithm by Hendler and Woelfel jT6], we consider a tree with N leafs and where 
each non-leaf node has A children. Every non-leaf node is associated with a lock. Each process is 
assigned a unique leaf in the tree and climbs up the tree by capturing the locks on nodes on its 
path until it has captured the lock at the root. Once a process locks the root, it can enter the 
Critical Section. 

The main difficulty is that of designing the locks associated with the nodes of the tree. A simple 
CAS object together with an "announce array" as used in [16] does not work. Suppose a process p 
captures locks of several nodes on its path up to the root and aborts before capturing the root lock. 
Then it must release all captured node locks and therefore these lock releases cause other processes, 
which are busy- waiting on these nodes, to incur RMRs. So we need a mechanism to guarantee some 
progress to these processes, while we also need a mechanism that allows busy-waiting processes to 
abort their attempts to capture node locks. In |16j progress is achieved as follows: A process p, 
before releasing a lock on its path, searches(with a random procedure) for other processes that are 
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busy-waiting for the node lock to become free. If p finds such a process, it promotes it into the 
critical section. This is possible, because at the time of the promotion p owns the root lock and can 
hand it over to a promoted process. Unfortunately, this promotion mechanism fails for abortable 
mutual exclusion: When p aborts its own attempt to enter the Critical Section, it may have to 
release node locks at a time when it doesn't own the root lock. Another problem is that if p finds 
a process q that is waiting for p to release a node-lock, then q may have already decided to abort. 
We use a carefully designed synchronization mechanism to deal with such cases. 

To ensure that waiting processes make some progress, we desire that p "collect" busy-waiting 
processes (if any) at a node into an instance of an object of type AbortableProArray A , PawnSet, 
using the operation collect (). Once busy-waiting processes are collected into PawnSet, p can 
identify a busy-waiting process, if present, using the PawnSet.promoteQ operation, while busy- 
waiting processes themselves can abort using the PawnSet. abort () operation. Note that p may 
have to read 0(A) registers just to find a single busy- waiting process at a node, where A is the 
branching factor of the arbitration tree. This is problematic since our goal is to bound the number 
of steps during a passage to 0(A) steps, and thus a process cannot collect at more than one node. 
For this reason we desire that p transfer all unreleased node locks that it owns to the first busy- 
waiting process it can find, and then it would be done. And if there are no busy-waiting processes 
at a node, then p should somehow be able to release the node lock in 0(1) steps. Since there 
are at most A nodes on a path to the root node, p can continue to release captured node locks 
where there are no busy-waiting processes, and thus not incur more than 0(A) overall. We use an 
instance of RCAScounter2, Ctr, to help decide if there are any busy- waiting processes at a node lock. 
Initially, Ctr is 0, and processes attempt to increase Ctr using the Ctr.incQ operation after having 
registered at the node. Process p attempts to release a node lock by first executing a Ctr. CAS (1,0) 
operation. If the operation fails then some process q must have further increased Ctr from 1 to 2, 
and thus p can transfer all unreleased locks to q, if q has not aborted itself. If q has aborted, then 
q can perform the collect at the node lock for p, since q can afford to incur an additional one-time 
expense of 0(A) RMRs. If q has not aborted then p can transfer its captured locks to q in 0(1) 
steps, and thus making sure some process makes progress towards capturing the root lock. We 
encapsulate these mechanisms in a randomized abortable lock object, ALockArray A . 

More generally, we specify an object ALockArray n for an arbitrary parameter n < N. Object 
ALockArray n provides methods lockQ and release () that can be accessed by at most n + 1 
processes concurrently. The object is an abortable lock, but with an RMR complexity of 0(n) for 
the abort- way, and constant RMR complexity for lock(). The release () method is special. If 
it detects contention (i.e., other processes are busy- waiting) , then it takes O(n) RMRs, but helps 
those other processes to make progress. Otherwise, it takes only 0(1) RMRs. Each non-leaf node 
u in our abritration tree will be associated with a lock ALockArray A and can only be accessed 
concurrently by the processes owning locks associated with the children of u and one other process. 

Method lock() takes a single argument, which we will call pseudo-ID, with value in 
{0, ... ,n — 1}. We denote a lockQ method call with argument i as lockjO, but refer to lockjO 
as lockQ whenever the context of the discussion is not concerned with the value of i. Method 
lockQ returns a non-_L value if a process captures the lock, otherwise it returns a _L value to indi- 
cate a failed lock() call. A lock() by process p can fail only if p aborts during the method call. 
Method release () takes two arguments, a pseudo-ID i € {0, . . . , n — 1} and an integer j. Method 
releasej(j) returns true if and only if there exists a concurrent call to lock() that eventually 
returns j. Otherwise method releasej(j) returns false. The information contained in argument j 
determines the transfered node locks. Process pseudo-IDs are passed as arguments to the methods 
to allow the ability for a process to "transfer" the responsibility of releasing the lock to another 
process. Specifically, we desire that if a process p executes a successful lockjO call and becomes 
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the owner of the lock, then p does not have to release the lock itself, if it can find some process 
q to call release^) on its behalf. In Section H] we implement object ALockArray n , and prove its 
properties in Appendix ID. 2\ and thus we get the following lemma. 

Lemma 3.1. Object ALockArray n can be implemented against the weak adversary for the CC model 
with the following properties using only 0(n) CAS objects and read-write registers. 

(a) Mutual exclusion, starvation freedom, bounded exit, and bounded abort. 

(b) The abort-way has 0{n) RMR complexity. 

(c) If a process does not abort during a lock() call, then it incurs 0(1) RMRs in expectation 
during the call, otherwise it incurs 0(n) RMRs in expectation during the call. 

(d) If a process' call to release (j) returns false, then it incurs 0(1) RMRs during the call, 
otherwise it incurs 0(n) RMRs during the call. 

High Level Description of the Abortable Lock. We use a complete A-ary tree T of height 
A with N leaves, called the arbitration tree. The root has height A and the leaves of the tree have 
height 0. The N processes in the system line up as N unique leaf nodes, such that each process p 
is associated with a unique leaf leaf p in the tree. Let path p denote the path from leaf p up to root, 
and h u denote the height of node u. 

Each node of our arbitration tree T is a structure of type Node that contains a single instance 
L of the abortable randomized lock object ALockArrayn. This allows processes the ability to abort 
their attempt at any point in time during their ascent to the root node. 

Lock capture protocol - lock p (). During lock p () a process p attempts to capture every 
node on its path path p that it does not own, as long as p has not received a signal to abort. Process 
p attempts to capture a node u by executing a call to u.L.lock(). If p's u.L.lockO call returns oo 
then p is said to have captured u, and if the call returns an integer j, then p is said to have been 
handed over all nodes from u to v on path p , where = j. We ensure that j > h u . Process p starts 
to own node u when p captures u.L or when p is handed over node u from the previous owner of 
node u. Process p can enter its Critical Section when it owns the root node of T ■ Process p may 
receive a signal to abort during a call to u.L.lockQ as a result of which p's call to u.L.lockQ 
returns either 1 or a non-_L value. In either case, p then calls release p () to release all locks of 
nodes that p has captured in its passage, and then returns from its lock p () call with value _L. 

Lock release protocol - release p (). An exiting process p releases all nodes that it owns 
during release p () . Process p is said to release node u if p releases u.L (by executing u.L. release () 
call), or if p hands over node u to some other process. Recall that p hands over node u if p executes 
a u.L. release (j) call that returns true where h v < h n < j. Let s be the height of the highest node 
p owns. During release^ () , p climbs up T and calls u.L.release p (s) at every node u that it owns, 
until a call returns true. If a ii.L.release p (s) call returns false (process p incurs 0(1) steps), 
then p is said to have released lock u.L (and therefore released node u), and thus p continues on 
its path. If a u.L.release p (s) call returns true (process p incurs 0(A) steps), then p has handed 
over all remaining nodes that it owns to some process that is executing a concurrent u.L.lockO 
call at node u, and thus p does not release any more nodes. 

Notice that our strategy to release node locks is to climb up the tree until all node locks are 
released or a hand over of remaining locks is made. Climbing up the tree is necessary (as opposed 
to climbing down) in order to hand over node locks to a process, say q, such that the handed over 
nodes lie on path g . 



8 



4 The Array Based Abortable Lock 



We specified object ALockArray n in Section [3] and now we describe and implement it (see Figures Q] 
and[2|). Let L be an instance of object ALockArray n . 

Registering and Roles at lock L. At the beginning of a lock() call processes register 
themselves in the apply array by swapping the value REG atomically into their designated slots 
(apply [i] for process with pseudo-ID i) using a CAS operation. The array apply of n CAS objects is 
used by processes to register and "deregister" themselves from lock L, and to notify each other of 
certain events at lock L. 

On registering in the apply array, processes attempt to increase Ctr, an instance of RCAScounter2, 
using operation Ctr.incO. Recall that RCAScounter2 is a bounded counter, initially 0, and returns 
values in {0,1,2} (see Section [2]). Each of these values corresponds to a role at lock L. There 
are four roles that a process can assume during its passage of lock L, namely king, queen, pawn 
and promoted pawn, and a role defines the protocol a process follows during a passage. During an 
execution, Ctr cycles from its initial value to non-0 values and then back to 0, multiple times, and 
we refer to each such cycle as a Ctr-cycle. The process that increases Ctr from to 1 becomes the 
king. The process that increases Ctr from 1 to 2 becomes the queen. All processes that attempt to 
increase Ctr any further, are returned value 2 (by specification of object RCAScounte^), and they 
assume the role of a pawn process. A pawn process busy- waits until it gets "promoted" at lock L 
(a process is said to be promoted at lock L if it is promoted in PawnSet), or until it sees the Ctr 
value decrease, so that it can attempt to increase Ctr again. We ensure that a pawn process repeats 
an attempt to increase Ctr at most once, before getting promoted. We ensure that at any point in 
time during the execution, the number of processes that have assumed the role of a king, queen and 
promoted pawn at lock L, respectively, is at most one, and thus we refer to them as king L , queen L 
and ppawn L , respectively. We describe the protocol associated with each of the roles in more detail 
shortly. An array Role of n read-write registers is used by processes to record their role at lock L. 

Busy- waiting in lock L. The king process, king L , becomes the first owner of lock L during 
the current Ctr-cycle, and can proceed to enter its Critical Section, and thus it does not busy-wait 
during lockQ. The queen process, queen L , must wait for king L for a notification of its turn to own 
lock L. Then queen L spins on CAS object Syncl, waiting for king L to CAS some integer value into 
Syncl. Process king L attempts to CAS an integer j into Syncl only during its call to release (j), 
after it has executed its Critical Section. The pawn processes wait on their individual slots of the 
apply array for a notification of their promotion. 

A collect action at lock L. A collect action is conducted by either king L during a call to 
release (), or by queen L during a call to abort (). A collect action is defined as the sequence 
of steps executed by a process during a call to doCollect () . During a call to doCollect () , the 
collecting process (say q) iterates over the array apply reading every slot, and then creates a local 
array A from the values read and stores the contents of A in the PawnSet object in using the 
operation PawnSet. collect (A) . A key point to note is that operation PawnSet. collect (A) does 
not overwrite an aborted process's value in PawnSet (a process aborts itself in PawnSet by executing 
a successful PawnSet. abort () operation). 

A promote action at lock L. Operation PawnSet.promoteO during a call to method 
doPromote () is defined as a promote action. The operation returns the pseudo-ID of a process that 
was collected during a collect action, and has not yet aborted from PawnSet. A promote action is 
conducted at lock L either by king L , queen L or ppawn L . 

Lock handover from king L to queen L . As mentioned, process queen L waits for king L to finish 
its Critical Section and then call release (j). During king L 's release (j) call, king L attempts 
to swap integer j into CAS object Syncl, that only king L and queen L access. If queen L has not 
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Object ALockArray n 



shared: 

Ctr: RCAScounter2 init 0; 

PawnSet: Object of type AbortableProArray„ init 0; 
apply: array [0 ... n — 1] of int pairs init all (_L, _L); 
Role: array [0 ... n — 1] of int init _L; 
Syncl,Sync2: int init _L; 

KING, QUEEN, PAWN, PAWN.P, REG, PRO: const int 0,1,2,3,4,5 respectively; 
getSequenceNo () : returns integer k on being called for the k-th time from a call to 

lockj(). (Since calls to lockjO are executed sequentially, a sequential shared 
counter 

suffices to implement method getSequenceNo () .) 
local: 

s,val,seq, dummy: int init _L; 
flag, r: boolean init false; 
A: array [0 ... n — 1] of int init !_ 
//If process i satisfies the loop condition in line [2], EL or 1141 . and i 
has received a signal to abort, then i calls abortjO 



Method locki( ) 



1 s ^— getSequenceNo () 

2 await (apply[i].CAS((_L, _L), (REG, s))) 

3 flag true 

4 repeat 

5 Role[i] <— Ctr.incO 

6 if (Role[i] = PAWN) then 

7 await 

(apply[z] = (PRO,s) VCtr.ReadO ^ 2) 

8 if (applyfi] = (PRO,s)) then 

9 | Role[i] <- PAWN.P 
10 end 

n end 

12 until (Role[i] G {KING, QUEEN, PAWN.P}) 

13 if (Role[i] = QUEEN) then 

14 | await (Syncl ^ _L) 

15 end 

16 apply[i].CAS((REG,s), (PRO,s)) 

17 if Role[i] = QUEEN then return Syncl else 
return oo 



Method abortj ( ) 



18 if —>flag then return _L 

19 apply[i].CAS((REG,s),(PRO,s)) 

20 if Role[il = PAWN then 



if -iPawnSet. abort (i, s) then 
Role[»] <- PAWN.P 
return oo 
end 



21 
22 
23 
24 

25 else 

26 if -iSyncl.CAS(±, oo) then 

27 ] return Syncl 

28 end 

29 doCollectjQ 

30 helpReleasej () 

31 end 

32 apply[i].CAS((PRO,s), (±,_L)) 

33 return _L 



Method doCollectjQ 



51 for k ^— to n — 1 do 

52 (val,seq) apply[fe] 

53 if vol = REG then A[k] 

54 end 

55 PawnSet. collect (A) 



seq else A[k] ^— _L 



Figure 1: Implementation of Object ALockArray„ 
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Method releasej (int j) 



34 r <— false 

35 if RoleM = KING then 

36 if -.Ctr.CAS(l,0) then 

37 r <- Syncl.CAS(_L, j) 

38 if r then doCollectj () 

39 helpReleasej () 

40 end 

41 end 

42 if Role[i] = QUEEN then 

43 | helpRelease^ () 

44 end 

45 if Rolefi] = PAWN.P then 

46 | doPromotej () 

47 end 

48 (dummy, s) apply [i] 

49 apply[z].CAS((PRO,s),(_L,±}) 

50 return r 



Method helpReleasejQ 



56 if -6ync2.CAS(_L,i) then 



57 
58 

59 
60 
61 
62 



j ^— Syncl.ReadO 
Syncl.CAS0',±) 
j «- Sync2.Read() 
Sync2.CAS (j, _L) 
PawnSet. remove (j) 
doPromotej () 



63 end 



Method doPromotejO 



64 PawnSet. remove (i) 

65 (j,seq) «— PawnSet. promote () 

66 if j = _L then 

67 PawnSet. reset () 

68 Ctr.CAS(2,0) 

69 else 

70 | apply [j]. CAS ((REG, seg), (PRO, seq)) 

71 end 



Figure 2: Implementation of Object ALockArray n (continued) 



"aborted", then king L successfully swaps j into Syncl, and this serves as a notification to queen L 
that king L has completed its Critical Section, and that queen L may now proceed to enter its Critical 
Section. 

Aborting an attempt at lock L by queen L . On receiving a signal to abort, queen L abandons 
its lock() call and executes a call to abort () instead. queen L first changes the value of its slot in 
the apply array from REG to PRO, to prevent itself from getting collected in future collects. Since 
king L and queen L are the first two processes at L, king L will eventually try to handover L to queen L . 
To prevent king L from handing over lock L to queen L , queen L attempts to swap a special value oo 
into Syncl in one atomic step. If queen L fails then this implies that king L has already handed over 
L to queen L , and thus queen L returns from its call to abort () with the value written to Syncl 
by king L , and becomes the owner of L. If queen L succeeds then queen L is said to have successfully 
aborted, and thus king L will eventually fail to hand over lock L. Since queen L has aborted, queen L 
now takes on the responsibility of collecting all registered processes in lock L, and storing them 
into the PawnSet object. After performing a collect, queen L then synchronizes with king L again, to 
perform a promote, where one of the collected processes is promoted. After that, queen L deregisters 
from the apply array by resetting its slot to the initial value (_L, _L). 

Aborting an attempt at lock L by a pawn process. On receiving a signal to abort a pawn 
process (say p) busy-waiting in lock L, abandons its lock() call and executes a call to abort () 
instead. Process p first changes the value of its slot in the apply array from REG to PRO, to 
prevent itself from getting collected in future collects. It then attempts to abort itself in PawnSet 
by executing the operation PawnSet. abort (p)). If p's attempt is unsuccessful then it implies that 
p has already been promoted in PawnSet, and thus p can assume the role of a promoted pawn, and 
become the owner of L. In this case, p returns from its abort () call with value oo and becomes the 
owner of L. If p's attempt is successful then p cannot be collected or promoted in future collects 
and promotion events. In this case, p deregisters from the apply array by resetting its slot to the 
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initial value (_L, _L), and returns _L from its call to abort (). 

Releasing lock L. Releasing lock L can be thought of as a group effort between the king L , 
queen L (if present at all), and the promoted pawns (if present at all). To completely release lock 
L, the owner of L needs to reset Ctr back to for the next Ctr-cycle to begin. However, the owner 
also has an obligation to hand over lock L to the next process waiting in line for lock L. We now 
discuss the individual strategies of releasing lock L, by king L , queen L and the promoted processes. 
To release lock L, the owner of L executes a call to release (j), for some integer j. 

Synchronizing the release of lock L by king L and queen L . Process king L first attempts to 
decrease Ctr from 1 to using a CAS operation. If it is successful, then king L was able to end the 
Ctr-cycle before any process could increase Ctr from 1 to 2. Thus, there was no queen L process or 
pawn processes waiting for their turn to own lock L, during that Ctr-cycle. Then king L is said to 
have released lock L. 

If king L 's attempt to decrease Ctr from 1 to fails, then king L knows that there exists a queen L 
process that increased Ctr from 1 to 2. Since queen L is allowed to abort, releasing lock L is not as 
straight forward as raising a flag to be read by queen L . Therefore, king L attempts to synchronize with 
queen L by swapping the integer j into the object Syncl using a Syncl.CAS(_L, j) operation. Recall 
that queen L also attempts to swap a special value oo into object Syncl using a Syncl. CAS (_L, j) 
operation, in order to abort its attempt. Clearly only one of them can succeed. If king L succeeds, 
then king L is said to have successfully handed over lock L to queen L . If king L fails, then king L knows 
that queen L has aborted and thus king L then tries to hand over its lock to one of the waiting pawn 
processes. The procedure to hand over lock L to one of the waiting pawn processes is to execute a 
collect action followed by a promote action. 

The collect action needs to be executed only once during a Ctr-cycle, and thus we let the process 
(among king L or queen L ) that successfully swaps a value into Syncl, execute the collect action. 

If king L successfully handed over L to queen L , it collects the waiting pawn processes, so that 
eventually when queen L is ready to release lock L, queen L can simply execute a promote action. Since 
there is no guarantee that king L will finish collecting before queen L desires to execute a promote 
action, the processes synchronize among themselves again, to execute the first promote action of 
the current Ctr-cycle. They both attempt to swap their pseudo-IDs into an empty CAS object Sync2, 
and therefore only one can succeed. The process that is unsuccessful, is the second among them, 
and therefore by that point the collection of the waiting pawn process must be complete. Then the 
process that is unsuccessful, resets Syncl and Sync2 to their initial value _L, and then executes the 
promote action, where a waiting pawn process is promoted and handed over lock L. If no process 
were collected during the Ctr-cycle, or all collected pawn processes have successfully aborted before 
the promote action, then the promote action fails, and thus the owner process resets the PawnSet 
object, and then resets Ctr from 2 to in one atomic step, thus releasing lock L, and resetting the 
Ctr-cycle. 

The release of lock L by ppawn L . If a process was promoted by king L or queen L as described 
above, then the promoted process is said to be handed over the ownership of L, and becomes the 
first promoted pawn of the Ctr-cycle. Since a collect for this Ctr-cycle has already been executed, 
process ppawn L does not execute any more collects, but simply attempts to hand over lock L to the 
next collected process by executing a promote action. This sort of promotion and handing over 
of lock L continues until there are no more collected processes to promote, at which point the last 
promoted pawn resets the PawnSet object, and then resets Ctr from 2 to in one atomic step, thus 
releasing lock L, and resetting the Ctr-cycle. 

All owner processes also deregister themselves from lock L, by resetting their slot in the apply 
array to the initial value (_L, _L). This step is the last step of their release (j) calls, and processes 
return a boolean to indicate whether they successfully wrote integer j into Syncl during their 
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release (j) call. Note that only king L could possibly return true since it is the only process that 
attempts to do so, during its release (j) call. 

5 Conclusion 

We presented the first randomized abortable lock that achieves sub-logartihmic expected RMR 
complexity. While the speed-up is only a modest O (log log n) factor over the most efficient de- 
terministic abortable mutual exclusion algorithm, our result shows that randomization can help in 
principle, to improve the efficiency of abortable locks. Unfortunately, our algorithm is quite compli- 
cated; it would be nice to find a simpler one. It would also be interesting to find an algorithm with 
sub-logarithmic RMR complexity that works against the stronger adversary. In the weak adversary 
model, no non-trivial lower bounds for mutual exclusion are known, but it seems hard to improve 
upon O (log nj log log n) RMR complexity, even without the abortability property. 

As shown by Bender and Gilbert, [8], the picture looks different in the oblivious adversary 
model. However, their algorithm is only lock-free with high probability. It would be interesting 
to find a mutual exclusion algorithm with o(logn/loglogn) RMR complexity against the oblivious 
adversary that is lock-free with probability one. It would also be interesting to know whether such 
an algorithm can be made abortable. 
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Appendix 



A Implementation of Object RCAScounterfc 

The sequential specification of the CAS Counter object is presented in Figure [3] in the form of type 
CAScounter^. The implementation of our randomized CAS counter object, RCAScounterfe of type 
CAScounterfc is presented in Figure HI A shared CAS object Count is used to store the value of the 
counter object, and is initialized to 0. The object provides methods inc(), CASO and Read(), 
where the inc() method is allowed to fail, in which case the operation does not change the object 
state, and returns _L to indicate the failure. 

Type CAScounterfc 
x: int init 



Operation inc() 


Operation CAS (old, new) 


1 if x = k then 
return x 

2 X <— X + 1 

3 return x — 1 


4 if x ^ old V new ^ {0, . . . , k} then return 
false 

5 x -(— new 

6 return true 



Operation 

ReadQ 

7 return 

x 



Figure 3: Sequential Specification of Type CAScou liters 



Object RCAScounterfc 



shared: Count: int init 
local: j3: int init 



Method inc( ) 


Method CAS(old,new) 


8 (3 random(0, 1, . . . , k) 

9 if (P = k) then 

10 | if (Count. Read() = k) then return k 
n else 

12 | if Count. CAS (/?,/? + 1) then return (3 

13 end 

14 return _L 


15 if new $l {0, . . . , k} then return 
false 

16 return Count. CAS (old, new) 


Method Read( ) 


17 return Count. ReadQ 



Figure 4: Implementation of Object RCAScounter/c 



During the inc() method, a process p first makes a guess at the counter's current value by 
rolling a (k + l)-sided dice (in line [8]) that returns a value in {0, . . . , k} uniformly at random, and 
stores the value in local variable /3. If f3 = k, then p performs a Read() on Count(in line llOj) to 
verify the correctness of its guess. If p's guess is correct, then it returns k, otherwise it returns 
_L (in line [T4"|) to indicate a failed inc() method call. If /3 S {0, . . . ,k — 1}, then p performs a 
Count. CAS j3 + 1) operation (in line fl0|) in order to verify the correctness of its guess and to 
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increment Count in one atomic step. If p's guess is correct, then the CAS operation succeeds and 
the inc() method returns the previous value. Otherwise the inc() method returns _L (in line I14p 
to indicate a failed inc() method call. 

Method Read() simply reads the current value of Count using a Count. Read() operation (line ll7j) 
and returns the result of the operation. Method CAS() takes two integer parameters old, new, and 
in line [15] performs a safety check, where it checks whether the value of new is in {0, . . . , k}. If 
the safety check fails, then the method simply returns false. Otherwise, it attempts to change the 
value of Count from old to new using the Count. CAS (old, new) operation (in line [TBI) and returns 
the result of the operation. 

A.l Analysis and Properties of Object RCAScounterfc 

Consider an instance of the RCAScounterfc object. Let H be an arbitrary history that consists of 
all method calls on the instance, except failed inc() calls and pending calls that are yet to execute 
line[10](Read operation), line[12](CAS operation), line[16j(CAS operation) or line[T7](Read operation). 
If a failed inc ( ) is in the history, it can be linearized at an arbitrary point between its invocation 
and response, as it does not affect the validity of any other operations. Therefore, it suffices to 
prove that the history without failed inc() operations is linearizable, and then linearizability of 
the original history follows. The same argument applies to omitting the selected pending method 
calls. Since the selected pending method calls do not change any shared object, they cannot affect 
the validity of any other operations. 

We define a point pt(u) for every method u in H. Let I{u) be the interval between u's invocation 
and response. Let S be the sequential history obtained by ordering the method calls in H according 
to the points pt(u). To show that RCAScounterfc is a randomized linearizable implementation of 
the type CAScounter^, we need to show that the sequential history S is valid, i.e., S lies in the 
specification of type CAScounter^ object, and that pt(u) lies in I(u). Let C be an object of type 
CAScounterfe, and let S v be the sequential history obtained when the operations of S are executed 
sequentially on object C in the order as given in S. Clearly, S v is a valid sequential history in the 
specification of type CAScounter^ by construction. Then to show that S is valid, we show that 
S = Sv . 

Lemma A.l. Object RCAScounter^ is a randomized linearizable implementation of type 
CAScounter/;. 

Proof. Let A be an instance of the RCAScounter^ object. Consider an arbitrary history H that 
consists of all completed method calls on A, except failed inc() calls, and all pending method calls 
on A that have executed a successful CAS operation. We now define point pt(u) for every method 
u in H . 

If it is a Read() method call then define pt{u) to be the point in time when the Read operation 
in line [17] is executed. 

If u is an inc() method call that returns from line [10] then pt(u) is the point in time of the 
Read operation in line [TOl and if it's CAS operation in line [12] succeeds then pt(u) is the point in 
time of the CAS operation in line [12] By construction, a Read or CAS operation has been executed 
during every inc() call in H, and no failed inc() calls are in H. Then it follows that we have 
defined pt{u) for every inc() call u in H. 

If u is a CAS() method call that returns from line 1151 then pt{u) is any arbitrary point during 
I(u), and if u returns from line 1161 then pt{u) is the point in time of the CAS operation in line 1161 

Clearly pt(u) G I{u) for every method u in H. 
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Let Ui be the i-th operation in S and Vi be the i-th operation in S v . Let Count(uj) + denote the 
value of object Count immediately after pt(ui), and let C(vi) + denote the value of object C after 
operation Vi in S v . We assume that uq is a method call that does not change the state of any 
shared object of instance A (such as a ReadQ method) and returns the initial value of the object. 
This assumption can be made without loss of generality, because the removal of a method call that 
does not change the state of the object from a linearizable history always leaves a history that 
is also linearizable. The purpose of the assumption is to simplify the base case of our induction 
hypothesis. 

We now prove by induction on integer i, that Count(uj) + = C(vi) + , and that the return value 
of Ui matches the value returned by Vi, thereby proving S — Sy . 

Basis (i = 0) Since initially the value of object Count and the value of the atomic CAScounterfc 
object is 0, it follows from the definition of the method call Uq, that Count(uo) + = C(vq) + = 0, and 
the return value of uq matches that of vq. 

Induction Step [i > 0) From the induction hypothesis, Count(uj_i) + = C(t>j_i) + . 

Case a - m is an inc() method call that executes a successful CAS() operation in line 1121 
Then pt(ui) is when object Count is incremented from (3 to /3 + 1 by a successful Count. CAS (/?, /3 + 1) 
operation in line [T2"| and thus Count(uj_i) + = [3 holds. Also, Ui returns f3 = Count(iii_i) + . Since 
m fails the if-condition of lineO j3 ^ k and therefore Count(iij_i) + = (3 ^ k holds. Now consider 
operation Vi in S v . Since C{vi-\) + = Count(iij_i) + ^ k, the if-condition of line CD fails, and the 
value of the atomic CAScounter^ is incremented in line [2] and C(t>j_i) + returned in line[3j Hence 
Count(nj) + = C{vi) + and the return values match. 

Case b - Uj is an inc() method call that returns from line 1101 Then pt(v,i) is when the 
Read() operation on the object Count is executed in line 1101 Clearly, the value returned by the 
Read() operation on the object Count at pt(ui) is Count(u,;_i) + . Since the if-condition of line [TOl is 
satisfied, Count(uj_i) + = k and Uj returns integer k without changing object Count. Now consider 
operation vi in S v . Since C(wj_i) + = Count(uj_i) + and Count(uj_i) + = k, the if-condition of 
line[T]is satisfied and integer k is returned without changing the atomic CAScounter/% object. Hence 
Count(uj) + = C(vi) + and the return values match. 

Case c - m is a CASO method call that returns from line[15j Then the if-condition of line PT51 is 
satisfied and thus new ^ {0, 1, . . . , k} and U{ returns false without changing Count. Now consider 
operation Vi in S v . Since new ^ {0, 1, . . . , k}, the if-condition of line U] will be satisfied and the 
Boolean value false is returned without changing the value of object C. Hence Count(nj) + = C{vi) + 
and the return values match. 

Case d - n, is a CASO method call that returns from line 1161 Then pt{ui) is when the 
CAS operation on the object Count is executed in line [To] and Ui returns the result of this CAS 
operation. The CAS operation attempts to change the value of Count from old to new, therefore if 
Count(uj_i) + = old then Count(uj) + = new and Ui returns true, or else Count remains unchanged 
and Ui returns false. Now consider operation Vi in S v . From the code structure, if C(t> = old 
then C(vi) + = new and the Boolean value true is returned. And if C(vi-i) + ^ old then the value of 
object C remains unchanged and the Boolean value false is returned. Hence Count(uj) + = C{vi) + 
and the return values match. □ 

Lemma A. 2. The probability that an inc() method call returns _L is k/(k + 1) against the weak 
adversary. 

Proof. Let the process calling the inc() method call (say u) be p and let the value of the object 
Count immediately before p executes line [8] be z. Since the adversary is weak, no other process 
executes a shared memory operation after p chooses (3 in line and before p finishes executing its 
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next shared memory operation. From the code structure, p returns _L during u (in line [T^|) if and 
only if z ^ /?. Since 



Prob(> ^ P) = 1 - ProbO = /3) = 1 



1 



k 



k+1 k + 1 
the claim follows. 

The following claim follows immediately from an inspection of the code. 
Lemma A. 3. Each of the methods of RCAScounter/j has step complexity 0(1), and is wait-free. 
Lemma 12.11 follows from Lemmas lA.lj , IA.2I and IA.31 



□ 



B Specification of Type AbortableProArray fc 

Type AbortableProArray fe is presented in Figure [5l 



Type AbortableProArray fc 



A: array [0 ... k - 1] of int pairs init all (_L, _L); REG, PRO, ABORT: int init 1, 2, 3 



Operation collect (int [] X) 



l for i •(— to k — 1 do 



(v, s) <- A[i] 

if v ^ ABORT A X[i] / 1 then A[i] 
(REG,X[i}) 



4 end 



Operation abort (int i, int seq) 



5 (v, s) A[i] 

6 if v = PRO then return false 

7 A[i\ <r- (ABORT, seq) 

8 return true 



Operation reset () 



9 for i «- to k - 1 do ^- (0, L) 



Operation promote () 


10 for z 


^— to /c — 1 do 


n 


(v,s) <- 


12 


if w = REG then 


13 




<- (PRO,s) 


14 




return (i, s) 


15 


end 


16 end 




17 return (_L, _L) 


Operation remove (int i) 


18 (v,s) 


<- A[i] 


19 


<- (ABORT, s) 



Figure 5: Sequential Specification of Type AbortableProArray fc 



C The Single-Fast-Multi-Slow Universal Construction 

In this section, rather than implementing object SFMSUnivConst(T), we implement a lock-free 
universal construction object SFMSUnivConstWeak(T), with slightly weaker properties than SFM- 
SUnivConst(T). An object implementation is lock-free, if in any infinite history H where processes 
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continue to take steps, and H contains only operations on that object, some operation finishes. Ob- 
ject SFMSUnivConstWeak(T) has the same properties as object SFMSUnivConst(T) except method 
doFast () is lock- free with unbounded step-complexity. 

There is a standard technique called operation combining [18] that can be applied to transform 
our lock-free object SFMSUnivConstWeak(T) to the wait-free object SFMSUnivConst(T) with 0(N) 
step complexity for method doFast ( ) . 

By applying the technique of operation combining we can transform our lock-free universal 
construction SFMSUnivConstWeak(T) into our wait-free object SFMSUnivConst(T). We however do 
not provide a proof of its properties. Doing so would be repeating the same "standard" proof ideas 
from [18j, and would result in increasing the size of the paper without contributing to the main 
ideas of this paper. We do provide proofs for our lock-free universal construction SFMSUnivConst- 
Weak(T), and the proofs illustrate the main idea from this section, i.e., how to achieve a linearizable 
concurrent implementation with support for a doFast () method of 0(1) step complexity. We now 
present the implementation of object SFMSUnivConstWeak(T) (see Figure [6|). 

Object SFMSUnivConstWeak(T) 

shared: mReg: int init (so, -L,0,0); fastOp: int init (_L,0); 

local: state, res, fc, sc, sl, sl, rl, r2, seq: int init 



Method doFast (op) 



1 (state, res, fc, sc) <— 
m Reg. Read () 

2 fastOp <- (op,fc + 1) 

3 if -ihelpFastQ then 
helpFast () 

4 (state, res, fc, sc) <(— 
mReg. Read () 

5 return res 



Method f {statei, op) 



6 state2 <— state generated when 
op is applied to object with 
state statei 

7 res <— result when op is applied 
to object with state statei 

8 return (state2,res) 



Method helpFast () 



9 (si, rl, fc, sc) <— mReg.ReadO 
10 (op, seq) «— fastOp. Read() 
n if fc > seq then return true 

12 (s2, r2) f (si, op) 

13 return 

mReg.CAS((sl, rl, fc, sc), (s2, r2, seq, sc)) 



Method perf ormSlow(op) 



14 repeat 

15 (sl, rl, fc, sc) ^— mReg.ReadO 

16 (s2,r2) <- f (sl,op) 

17 if s2 = sl then return r2 

18 helpFast () 

19 until 

mReg. CAS ((sl, rl, fc, sc), (s2, rl, fc, sc + 1)) 

20 return r2 



Figure 6: Implementation of Object SFMSUnivConstWeak(T). 



Shared Data. A shared register mReg stores a 4-tuple (mQ,m\,m2,mz)- We use the notation 
mReg[z] to refer to the (i + l)-th tuple element, rrii, stored in register mReg. Element mReg[0] 
stores the state of object 0. Element mReg[l] stores the result of the most recent fast operation 
performed. Elements mReg[2] and mReg[3] store counts of the number of fast and slow operations 
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performed respectively. Initially mReg[0] stores the initial state of 0, mReg[l] has value _L and 
(mReg[2],mReg[3]) is (0,0). 

A shared register fastOp is used to announce a fast operation to be performed in a pair (so, s%). 
Element fastOp[0] stores the complete description of a fast operation to be performed. Element 
fastOp[l] stores a sequence number indicating the number of fast operations that have been an- 
nounced in the past. This sequence number is used by processes to determine whether an announced 
fast operation is pending execution. Initially fastOp is (_L, 0). The methods doFast () and doSlowO 
make use of two private methods helpFastO and f () (see Figure [6]). 

Description of the f () method. Method f is implemented using the specification provided 
by type T. The method takes two arguments state% and op, where state% is a state of object and 
op is the complete description of an operation to be applied on object 0. The method computes 
the new state state? and the result result, when operation op is applied on object with state 
state\. The method then returns the pair (state2, result). Since no shared memory operations are 
executed during the method, the method has step complexity. 

Description of the doFastO method. Let p be a process that executes doFast(op). In 
line[TJ process p first copies the 4-tuple read from register mReg to its local variables state, res, fc 
and sc. Then p announces the operation op by writing the pair (op, fc + 1) to register fastOp in 
line [21 After announcing the operation, process p helps perform the announced operation by calling 
the private method helpFast () in line[3l If the call to helpFast () returns false, then p concludes 
that the announced operation may not have been performed yet. In this case p makes another call 
to helpFast () in line [3] to be sure that the announced operation is performed (we prove later 
that at most two calls to helpFast () are required to perform an announced operation). Process 
p then reads and returns the result of the performed operation stored in mReg[l] in line U] and [5J 
respectively. Since method doFastO is not executed concurrently (by assumption), the result of 
p's operation stored in register mReg is not overwritten before the end of p's doFast(op) call. 

Description of the helpFast () method. Let q be a process that calls and executes 
helpFast (). In line [9j process q first copies the 4-tuple read from register mReg into its local 
variables si, rl, fc and sc. The value read from mReg[0] constitutes the state of object 0, to which 
q will attempt to apply the announced operation if required. The value read from mReg[l] is the 
result of the last fast operation performed on object 0. The value read from mReg[2] and mReg[3] 
is the count of the number of fast and slow operations performed respectively. Process q then 
reads fastOp in linetTUlto find out the announced operation op and the announced sequence number 
seq. Process q then determines whether the announced operation has already been performed, by 
checking whether seq is less than or equal to fc in line [TTJ If so, q concludes that operation op 
has been performed and returns true, otherwise it attempts to perform op in lines 1121 and 1131 In 
line [12] process q calls the private method f () to compute the new state s2 and the result r2 when 
operation op is applied to object with state si. In line 113} process p attempts to perform op by 
swapping the 4-tuple (si, rl, fc, sc) with (s2, rl, fc + 1, sc) using a CAS operation on mReg. If the 
CAS is unsuccessful then no changes are made to mReg. This can happen only if some other process 
performs an announced fast operation in line [13] or a slow operation in line [191 The result of the 
CAS operation of line [13] is returned in either case. 

Description of the doSlowO method. Let p be a process that calls and executes doSlow (op) . 
During the method, p repeats the while-loop of lines [T5lfT9l until p is able to successfully apply its 
operation op. In line [151 process p first copies the 4-tuple read from register mReg to its local 
variables sl,rl,fc and sc. In line [16] process q calls the private method f () to compute the new 
state s2 and the result r2 when operation op is applied to object with state si. In the case 
that operation op does not cause a state change in object 0, i.e., si = s2, then p returns result 
r2 in line El Otherwise p attempts to apply operation op in line HH by swapping the 4-tuple 
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(si, rl, fc, sc) with (s2,r2, fc, sc + 1) using a CAS operation on register mReg. Before attempting 
to apply its own operation in line 1191 p makes a call to helpFastQ in line 1181 to help perform an 
announced fast operation (if any). On completing the while-loop, p would have successfully applied 
its operation op, and thus p returns the result of the applied operation in line l20l 

The following lemma (proven in Section \C.2\i summarizes the properties of object SFMSUniv- 
ConstWeak(T). 

Lemma C.l. Object SFMSUnivConstWeak(T) is a lock-free universal construction object that im- 
plements an object O of type T, for n processes, where n is the maximum number of processes 
that can access object SFMSUnivConstWeak(T) concurrently and operations on object © are per- 
formed using either method doFast () or doSlowO , and no two processes execute method doFast () 
concurrently. Method doFast ( ) has 0(1) step complexity. 

C.l Operation Combining Technique 

In principle the technique works as follows: Processes maintain an iV-element array, say announce, 
where process i "owns" slot i, and processes store in their respective slots the operation that they 
want to apply. When a process p wants to apply an operation it first "announces" its operation 
by writing the operation to the p-th element of the array. Then p attempts to help the "next" 
operation in the announce array by attempting to apply that operation if it has not been applied, 
yet. An index to the "next" operation to be applied is maintained in the same register that stores 
the state of the concurrent object. Every time an announced operation is applied, the index is 
also incremented modulo N in one atomic step. The response of applied operations is stored in 
another iV-element array, say response, which can sometimes be combined with the announce array. 
Sequence numbers are used to ensure that an announced operation is not applied more than once. 
Since the index of the "next" operation cycles the announce array, a process needs to help announced 
operations 0(N) times before its own announced operation is applied, at which point it can stop. 

Herlihy [18] introduced this technique as a general methodology to transform lock-free universal 
constructions to wait-free ones. Herlihy presents another example [19] that employs the technique 
of operation combining to transform a lock-free universal construction to a wait-free one, where the 
step complexity of the method that performs the operation is bounded to O(N). 

On applying the standard technique of operation combining [18] to object SFMSUnivConst- 
Weak(T) we obtain object SFMSUnivConst(T) and Lemma [2^21 

C.2 Analysis and Proofs of Correctness of Object SFMSUnivConstWeak(T) 

Let a helpFast () method call that returns true in line[13](on executing a successful CAS operation) 
be called a successful helpFast (). 

Claim C.2. (a) The value o/fastOp[l] changes only in line\^ 

(b) The value of mReg[3] increases by one with every successful CAS operation in line{W^ and no 
other operation changes mReg [3]. 

(c) The value of mReg [2] increases with every successful CAS operation in line{T^ (during a suc- 
cessful helpFast () ), and no other operation changes mReg[2]. 

Proof. Part jaj) follows immediately from an inspection of the code. Register mReg is changed only 
when a process executes a successful CAS operation in linesll3lorll91 Furthermore, in line [13] mReg [3] 
is not changed and in line 1191 mReg[2] is not changed. Since, in line 1191 mReg[3] is incremented 
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Part (jbj) follows immediately. Now, for a process to execute line [T3l the if-condition of line Qj] must 
fail, hence mReg[2] is increased from its previous value and Part (jcj) follows. □ 

Consider an arbitrary history H where processes access an SFMSUnivConstWeak(T) object but 
no two doFastO method calls are executed concurrently. Since the fast operations are executed 
sequentially the happens before order on all doFastO method calls in H is a total order. 

Claim C.3. Let Ut be the t-th doFastO method call in history H being executed by process pt- 
For t > 1 let at be the point in time when pt executes line [2 during ut and 74 be the point when 
Pt is poised to execute line\Q Let ut 's helpers be the processes that call helpFastO such that the 
value read by the processes in line{]M is the value written to register fastOp at at- Let j3t be the 
first point in time when a helper's call to helpFastO succeeds after at- Let ao, A),7o be the start 
of execution H . Then the following claims hold for all t > 0: 

(51) Pt exists and j3 t is in (at, "ft) 

(5 2 ) Throughout (a t ,(3 t ) • fastOpfl] = mReg[2] + 1 = t 

(53) Throughout (/3 t ,a t+1 ) : fastOpfl] = mReg[2] = t 

Proof. We prove claims (Si), (S%) and (53) by induction over t. 

Basis: For t = 0, (Si) and (5*2) are trivially true. By assumption the initial value of fastOp[l] 
and mReg[2] is 0. Consider the interval (/3q, ai). From Claim ICT2l faj) it follows that fastOp is written 
for the first time at ai. The first point when one of the invariants (S3) is destroyed is if a process 
(say p) executes a successful CAS operation in line [13] during (/3q, ai). Then p read the value from 
register fastOp[l] in line 1101 since the initial value of fastOpfl] is and fastOp[l] is written to for 
the first time at a\. Since mReg[2] is never decremented (from Claim ICT2l jcl)) and mReg[2] initially 
has value 0, p satisfies the if-condition of line 1111 and p's helpFastO call returns true in line 1111 
Therefore, p does not execute line [T3l which is a contradiction. 

Induction Step: For t > 1: 

Proof of (Si): Consider the interval (at,^t)- To show that (Si) holds for t, we need to show 
that mReg[2] is changed during (at, 74). Consider pt's first call to helpFastO in line [3] during 
ut- From induction hypothesis (S3) for t — 1, it follows that fastOpfl] = mReg[2] = t — 1 during 
(fit-i, at). Then pt reads value t — 1 from mReg[2] in lineQ]and writes value t to fastOpfl] in lineEJ 
Since fastOp[l] is changed only at at+i after at, it follows that pt reads t from register fastOp[l] in 
lined! 

Case a - pt returns from line [11] Then pt read a value from mReg[2] in line [9] that is at least t. 
Since mReg[2] = t — 1 holds immediately before at some process changed mReg[2] in line 1131 during 
(at,jt)- Hence, (Si) for t holds. 

Case h - pt returns true from line[l3l Then pt has changed mReg[2] and hence (Si) holds for 

t. 

Case c - pt returns false from line [13] Then some process q changed register mReg after pt 
read mReg in line [9] Now, register mReg is written to only in line [13] or line [191 (from an inspection 
of the code). 

Subcase cl - q changed mReg by executing line[13l Then q has changed mReg [2] and hence 
(Si) holds for t. 

Subcase c2 - q changed mReg by executing line [191 Then pt executes a second call to 
helpFastO in line[3l Let m be the value of mReg[3] read by pt in line[9l If pts second helpFastO 
call satisfies case (a) or (b) then we get that (Si) holds for t. 
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If pt's second helpFastQ call returns false from line 1131 then some process changed mReg 
after pt read m Reg in line EE If some process changed m Reg by executing line [13] then we get that 

(51) holds for t. Then some process changed mReg by executing line [19] after pt read mReg in line[9] 
and let r be the first process to do so. Therefore, r changes the value of mReg[3] from mtom+1 
in line [19] Then r executed line [15] after q executed a successful CAS operation in line [T9l Then 
r completed a call to helpFastQ in line [18] after at- Since r reads mReg after at, r satisfied the 
if-condition of line [11] and executed line [T3l If r successfully executes the CAS operation in line [T3l 
then we get that (Si) holds for t. Then some process s must have changed mReg after r read mReg 
in line [9] Since the value of mReg[3] is only incremented (by Claim ICT27 b)) and r changes the value 
of mReg[3] from m to m + 1, it follows that s changed mReg in line [13] and hence (Si) holds for t. 

Proof of (S2) and (S3): From (Si) for t it follows that fit exists and at < fit < It < ott+i- 
From the induction hypothesis invariants (S2) and (S3) are true until at- Now, one of the invariants 

(52) or (S3) can be destroyed only if some process executes a successful CAS operation in line [TBI 
and changes mReg[2]. By definition of fit, mReg[2] is unchanged during (at, fit)- Then invariants 
(S2) and (S3) continue to hold until fit. Therefore, claim (S2) holds for t. It still remains to be 
shown that claim (S3) holds for t. 

Let p be the process that executes a successful CAS operation in line 1131 and changes mReg [2] 
at fit- Since mReg [2] = t — 1 immediately before fit and p executes a successful CAS operation in 
line [TBI at fit, p.fc = t — 1. Then p executed lines l9l and [TUI during (at, fit) and p.seq = t. Therefore, 
invariant (S3) is true immediately after fit- 

Now, assume another process (say q) destroys one of the invariants (S3) or S4 by executing a 
successful CAS operation in line [13] during (fit,at+i). Then q must have read register mReg[2] and 
fastOpfl] after fit, and therefore q must read the value t from both of them. Then q must have 
satisfied the if-condition of line [UJ and returned true. Hence, q does not execute line 1131 which is 
a contradiction. Therefore, invariant (S3) is true up to at+i> an d thus claim (S3) holds for t. □ 

Let H' be a history that consists of all completed method calls in H and all pending method 
calls that executed line [2] (Write operation on register fastOp), or which executed a successful 
CAS operation in line [13] or line [19] We omit all other pending method calls, since during those 
method calls no operations are executed that changes the state of any shared object, and hence 
those pending method calls cannot affect the validity of any other operation. Therefore, to prove 
that history H is linearizable it suffices to prove that history H' is linearizable. 

For each method call u in H' , we define a point pt(u) and an interval I(u). Let I(u) denote 
the interval between u's invocation and response. If u is a doSlowQ method call that returns from 
line [17] then pt(u) is the point in time of the Read operation in line [T5l otherwise, pt(u) is the 
point in time of the CAS operation in line [19] If u is a doFastO method call, let v be a successful 
helpFastO method call such that v's line[l3]is executed after u's line[2]and before u returns. We 
define pt(u) to be the point of the successful CAS operation in v 's line [13] 

Claim C.4. For every method call u in H , pt(u) exists and lies in I(u). 

Proof. There are two types of method calls in H, doFastO and doSlow(). 
Case a - u is a doFastO method call. 

From Claim [C73l it follows that exactly one of u's helpers (see Claim ICT3l for definition) succeeds 
and the helper performs a successful CAS operation in line [13] at some point in I(u). Therefore, 
point pt(u) exists and lies in I(u). 

Case b - u is a doSlowQ method call. By definition pt(u) is assigned to a line of u's code, 
therefore pt(u) exists and lies in I(u). □ 
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Let S be the sequential history obtained by ordering all method calls u in H' according to the 
points pt(u). To show that SFMSUnivConstWeak(T) is a linearizable implementation of an object 
of type T, we need to show that the sequential history S is valid, i.e., S lies in the specification of 
type T, and that pt(u) lies in I(u) (already shown in Claim IC~4l) . Let S v be the sequential history 
obtained when the operations of S are executed sequentially on object 0, as per their order in S. 
Clearly, S v is a valid sequential history in the specification of type T by construction. Then to 
show that S is valid, we show that S = S v . 

Let vt be the t-th operation in S v and let ut be the i-th method call in S. Let UC^ and UC^ 
denote the value of mReg[0] immediately before and after pt(ut), respectively. Let 0j~ and Of 
denote the state of object immediately before and after operation vt, respectively. Let at and 
Pt denote the value returned by ut and vt, respectively. Define UCq~ = UC^~ and 0q~ = 07- Define 
"o = Po = -L. 

Claim C.5. Suppose a process calls method f (xi, op) and the method returns the value pair (x2,y). 
If xi = O^T then X2 = Of and y = Pt- 

Proof. By definition, a call to method f (xi, op) returns the value pair (x2,y) such that X2 is the 
state of when operation op is applied to while at state x\ and y is the result of the operation. 
Then if x\ = then X2 = Of and y = Pt- □ 

Claim C.6. For allt>l. 

(St) Of = W and UC+ = UC m 

(s 2 ) uq- = o t - 

(S 3 ) UC+.J = Of_ x and a t -i = Pt-i 

Proof. Proof of (Si): Since operations in S v are executed sequentially, it follows that 0^ = t ^ 1 . 
We now show that UCf = UC^ +1 . Assume HCf ^ UC t ^ 1 . Then some process p changed the 
value of mReg[0] by executing a successful CAS operation in line [13] or line [19] at some point during 
the interval (pt(ut) , pt(ut+i)) ■ By definition, p's successful CAS operation in line [13] or line 1191 is 
pt(ug) for some method call ug where ug is the ^-th method call in H' . Thus, t is an integer and 
t < £ < t + 1 holds, which is a contradiction. 

Proof of (S2) and (-S3): We prove (S2) and (S3) by induction over t. 

Basis (t = 1) - By assumption, initially, mReg[0] is the initial state of 0, hence, UC^ = Oj - . 
Hence, (S2) is true. (S3) is true trivially. 

Induction Step - We assume (S2) and (S3) for t are true and prove that (S2) and (S3) for 
t + 1 are true. From (Si) we have, 0^ = 0^ and UC^~ = UC^ fl . From (S3) for t we have UC^ = 
0^. Therefore, it follows that UC^ = 0^ +1 and thus (S2) for t + 1 is true. 

To show (S3) for t + 1 is true, we need to show UC^~ = 0^" and at = Pt- By Claim (S2) for t, 
UC^ = holds. Let pt be the process executing ut- 

Case a - Ut is a doSlow(op) method call: Let xi be the most recent value read by pt from 
mReg[0] in line [15] and let (x2,y) be the value returned when pt executes line [16] From the code 
structure, at = y. 

Subcase (al) - pt returns from line I17t Then pt(ut) is the point when pt executes a successful 
Read operation on register mReg in line 1151 Since p satisfies the if-condition of line 1171 X2 = x\. 
Thus, uq~ = UC t + = x x . 

Subcase (a2) - pt returns from line [20] Then pt(ut) is the point when pt executes a successful 
CAS operation on register mReg in line [19] From the definition of a CAS operation, it follows that 
UQ" = x\ and UC^ = X2- 
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For both subcases (al) and (a2), x\ = UC^T = holds. Then from Claim [C31 it follows that 
%2 = Of and y = j3 t . Since X2 = HCf and y = at, Of = UCf and at = fit- 
Case b - Ut is a doFast (op) method call: Then pt(ut) is the point when a successful CAS 
operation on register mReg is executed in line [13] of method call w where w is the first successful 
helpFastQ method call that begins after ut's line [2] is executed. Let q be the process executing 
w. Let x\ be the value read by q from mReg[0] in line [9] and let (x2,y) be the value returned when 
q executes line 1121 From the definition of a CAS operation, it follows that UCJ~ = x\ and UC^ = 
X2- Since x% = UC^ = 0^ , from Claim IC~5l it follows that X2 = Of and y = (3 Ut . Since X2 = UC^, 
it follows that Of = \JCf. 

From Claim [CT3l if follows that mReg[l] is changed exactly once during ut, specifically at pt(ut), 
where q writes the value y to it. Thus, p reads the value y from mReg[l] in lined] since P executes 
line H] after pt(ut) (Claim |C~3|) . Therefore, it follows that a Ut = y = /3 Ut . □ 

Lemma C.7. History H' has a linearization in the specification of T. 

Proof. By Claim [CT4] for each method call u in H' , pt(u) exists and lies in I(u). Thus, to show 
that H' is linearizable we only need to show that S lies in the specification of type T. Thus, we 
need to show that for all t > 1, the value returned by vt matches that value returned by ut- From 
Claim [CTBl (S3) it follows that for all t > 1, at = A- D 

Lemma C.8. Object SFMSUnivConstWeak(T) is lock-free. 

Proof. Suppose not. I.e., there exists an infinite history H during which processes take steps but 
no method call finishes. It is clear from an inspection of method doFastO and private method 
helpFast () , that both methods are wait-free. Then if H contains steps executed by a process that 
executes a call to doFastO then the doFastO method call finishes since processes continue to take 
steps in history H - a contradiction. Now consider the only other case, where history H contains 
steps executed by processes only on doFastO method calls. Consider a process p that takes steps 
in history H and fails to complete its doSlowQ method call. Then during p's execution p reads 
register m Reg in line [15] and fails its CAS operation in line [19] during an iteration of the loop of 
lines H4tfT9l Now p's CAS operation can fail only if some process executes a successful CAS operation 
in line [13] or line 1191 between p's ReadQ and CAS operation. 

Case a - Some process q executes a successful CAS operation in line [19] Then q breaks out of 
the loop of lines ll4tfT9l Since processes continue to take steps in our infinite history H, q eventually 
returns from its doSlowO method call - a contradiction. 

Case b - Some process q executes a successful CAS operation in line [T3l Then q has performed 
a successful helpFast () method call and incremented mReg[2]. Let the value of mReg[2] after the 
increment be z. Now consider the next iteration of the loop by process p, where p's CAS operation in 
line 1191 fails again. Since Case a leads to a contradiction, some process r executed a successful CAS 
operation in line[l3] Then r read incremented mReg[2] to some value greater than z in line!13[ From 
the code structure of the helpFast () method, r failed the if-condition of line llll and therefore r 
read seq = fastOpfl] > z in linetTUl Since fastOp[l] is incremented only in line [2] during a doFastO 
method call, it follows that a doFastO method was called after q incremented mReg[2] to z in 
line [13] This is a contradiction to the assumption that processes take steps executing only method 
doSlowO during our history H. □ 

Lemma IC.ll follows from Lemma IC.7I and IC.81 
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D The Array Based Randomized Abortable Lock 



D.l Implementation / Low Level Description 

We now describe the implementation of our algorithm in detail. (See Figure [T] and [2|) . We now 
describe the method calls in detail and illustrate the use of each of the internal objects as and when 
we require them. 

The lock() method. Suppose p executes a call to lockj () . Process p first receives a sequence 
number using a call to getSequenceNoQ in line [1] and stores it in its local variable s. Method 
getSequenceNo () returns integer k on being called for the fc-th time from a call to lockjQ. 
Since calls to lockjO are executed sequentially, a sequential shared counter suffices to implement 
method getSequenceNo () . Method getSequenceNo () is used to return unique sequence number 
which helps solve the classic ABA problem. The ABA problem is as follows: If a process reads an 
object twice and reads the value of the object to be 'A' both times, then it is unable to differentiate 
this scenario from a scenario where the object was changed to value 'B' in between the two reads 
of the object. Process p then spins on apply [i] in line[2] until p registers itself by swapping the value 
(REG,s) into apply [i] using a CAS operation. Processes write the value REG in the apply array to 
announce their presence at lock L. 

Process p then executes the role-loop, lines l4lfT2"l until p either increases the value of Ctr to 1 or 
2, or until p is notified of its promotion. Process p begins an iteration of the role-loop by calling 
the Ctr.incQ operation in line [5] and stores the returned value into Role[i]. The returned value 
determines p's current role at lock L. The shared array Role is used by process p to store its role in 
slot Role[i], which can later be read to determine the actions to perform at lock L. This is important 
because we want to allow the behavior of transferring locks. Specifically, to enable a process q to 
call releasej () on behalf of p, q needs to determine p's role at lock L, which is possible by reading 
Role[i]. 

If the Ctr.incO operation in line [5] fails, i.e., it returns _L, then p repeats the role-loop. Such 
repeats can happen only a constant number of times in expectation (by Claim [A2l) . If the value 
returned in line [5] is or 1, then p has incremented the value of Ctr (from the semantics of a 
RCAScounter2 object), and it becomes king L or queen L , respectively, and breaks out of the role-loop 
in line [12j 

If p becomes king L in line then p fails the if-condition of line [13] and proceeds to execute 
lines [ToTTm In line \16\ p changes apply [i] to the value (PRO,s), to prevent itself from getting 
promoted in future promote actions. In line 1171 p returns from its lock() call by returning the 
special value oo (a non-_L value indicating a successful lock() call), since p is king L . 

If p becomes queen L in line then p knows that there exists a king process at lock L, and 
thus queen L proceeds to spin on Syncl in line 1141 awaiting a notification from king L . Recall that 
king L notifies queen L of queen L 's turn to own lock L by writing the integer j into Syncl during a 
release (j) call. Once p receives king L 's notification (by reading a non-_L value in Syncl in line I14p . 
p breaks out of the spin loop of line [EH and proceeds to execute lines [ToTTm In line [16j p changes 
apply [i] to the value (PRO,s), to prevent itself from getting promoted in future promote actions. 
In line 1171 p returns from its lock() call by returning the integer value stored in Syncl (a non-_L 
value indicating a successful lockQ call). 

If the value returned in line[5]is 2, then p does not become king L or queen L , and thus p assumes 
the role of a pawn. Process p then waits for a notification of its own promotion, or, for the Ctr 
value to decrease from 2, by spinning on apply [i] and Ctr in line [71 When p breaks out of this spin 
lock, it determines in line [8] whether it was promoted by checking whether the value of apply [i] 
was changed to (PRO,s). A process is promoted only by a king L , queen L or a ppawn L during their 
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release () call. If p finds that it was not promoted, then p is said to have been missed during 
a Ctr-cycle, and thus p repeats the role-loop. We later show that a process gets missed during at 
most one Ctr-cycle. 

If p was promoted, then it writes a constant value PAWN_P = 3 into Rolefi] in line[9]and becomes 
ppawn L . Since p has been promoted, p knows that both king L and queen L are no longer executing 
their entry or Critical Section, and thus p owns lock L now. Then p goes on to break out of the 
role-loop in line 1121 an d proceeds to return from its lock() call by returning the special value oo 
(a non-_L value indicating a successful lock() call), since p is ppawn L . 

The release () method. Suppose p executes a call to releasej(j') with an integer argument 
j. We restrict the execution such that a process calls a releasej(j) method only after a call to a 
successful lockjO has been completed. 

In line 1344 p initializes the local variable r to the boolean value false. Local variable r is returned 
later in line[50]to indicate whether the integer j was successfully written to Syncl during the release 
method call. In lines [35] 02] and 05] process p determines its role at the node and the action to 
perform. In line 1491 process p deregisters itself from lock L by swapping (_L, _L) into apply[i]. At 
the end of the method call a boolean is returned in line [50] indicating whether the integer j was 
written to Syncl. 

If p determines that it is king L , then it attempts to decrease Ctr from 1 to in line 1361 This 
decrement operation will only fail if there exists a queen process at lock L which increased the Ctr 
to 2 during its lock () call. If the decrement operation fails then p has determined that there exists 
a queen process at lock L and it now synchronizes with queen L to perform the collect action. Recall 
that CAS object Syncl is used by king L and queen L to determine which process performs a collect. 
In line [371 P attempts to swap integer j into Syncl by executing a Syncl. CAS (_L, j) operation and 
stores the result of the operation in local variable r. If p is successful then it performs the collect 
action by executing a call to doCollectj () in line[38j If p is unsuccessful then it knows that queen L 
will perform a collect. In line [39] p calls the helpReleasej () method to synchronize the release of 
lock L with queen L . We describe the method helpRelease () shortly. 

If p determines that it is queen L , then it calls the helpRelease^ () method call in line 1431 to 
synchronize the release of lock L with king L . 

If p determines that it is a promoted pawn, then it attempts to promote a waiting pawn by 
making a call to doPromote () in line 1461 

The doCollectO method. Suppose a process p executing a doCollectjO method call. The 
collect action consists of reading the apply array (left to right), and creating a vector A of n values, 
where the k-th. element is either _L (to indicate that the process with pseudo-ID k is not a candidate 
for promotion) or an integer sequence number (to indicate that the process with pseudo-ID k is 
a candidate for promotion). The vector A is stored in the AbortableProArray ra instance PawnSet 
in line [55] using a PawnSet. collect (^4) operation. The PawnSet. collect (^4) operation ensures 
that if the k-th element of PawnSet has value 3 = ABORT (written during a PawnSet. abort (k, •) 
operation), then the k-th element is not overwritten during the PawnSet. collect (^4) operation. 
This is required to ensure that processes that have expressed a desire to abort are not collected 
and subsequently promoted. 

The helpRelease () method. Suppose king L calls helpRelease^ () and queen L calls 
helpRelease^ () . During the course of these method calls, king L and queen L synchronize with 
each other in order to reset CAS objects Syncl and Sync2, remove themselves from PawnSet, pro- 
mote a collected process and notify the promoted process. If no process is found in PawnSet that 
can be promoted, then the PawnSet object is reset to its initial state and Ctr reset to 0. Recall that 
CAS object Sync2 is used as a synchronization primitive by king L and queen L to determine which 
process exits last among them, and thus performs all pending release work. In line [56] the process 
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which swaps value i or k into Sync2 by executing a successful CAS operation, exits, and the other 
process performs the pending release work in lines [57] - 1631 Let us now refer to this other process 
as the releasing process. In lines 1571 - 1581 the releasing process resets Syncl to its initial value _L. In 
lineEU the releasing process reads the pseudo-ID written to Sync2 by the exited process (process 
that executed a successful CAS operation on Syncl). The pseudo-ID written to Sync2 is required 
to remove the exited process from getting promoted in a future promote in case it was collected 
in PawnSet. In line 16 1\ the releasing process removes the exited process from PawnSet. CAS object 
Sync2 is reset to its initial value _L in line[60l In line I62[ the releasing process calls doPromote () 
to promote a collected process. 

The doPromote () method. Suppose p executes a call to doPromotej () . In line 1641 p removes 
itself from PawnSet by executing a PawnSet. remove (i) operation. It does so to prevent itself 
from getting promoted in case it was collected earlier. In line [65| p performs a promote action 
by executing a PawnSet.promoteO operation. If a process was collected and the process has not 
aborted then its corresponding element (fc-th element for a process with pseudo-ID k) in PawnSet 
will have the value (REG,-). If a process has aborted then its corresponding element in PawnSet 
will have the value (PRO, •}. 

If a successful promote () operation is executed then an element in PawnSet is changed from 
(REG, s) to (PRO,s), where s £ N, and the pair (k,s) is returned, where k is the index of that 
element in PawnSet. In this case we say that process with pseudo-ID k was promoted. If an 
unsuccessful promoteO operation is executed, then no element in PawnSet has the value (REG,s), 
where s € N, and thus the special value (_L, _L) is returned. We then say that no process was 
promoted. The returned pair is stored in local variables (j, seq) in line [65] 

If no process was promoted, then p resets PawnSet to its initial value in line[67Jusing the reset () 
operation, and decreases Ctr from 2 to in line[68l If a process was found and promoted in PawnSet, 
then that process is notified of its promotion, by swapping its corresponding apply array element's 
value from REG to PRO using a CAS operation in line 1701 

Recall that, while executing a lock() method call a process may receive a signal to abort. 
Suppose a process p receives a signal to abort while executing a lockjO method call. If process p 
is busy- waiting in lines [21 [7] or [TH then p stops executing lockjO, and instead executes a call to 
abortjO. If p is poised to execute any line [TBI or [T7l then it completes its call to lockjO. If p is 
poised to execute any other line then it continues executing lockjO until it begins to busy- wait 
in lines l2l [71 or I14[ at which point it stops and calls aborts (). If p does not begin to busy- wait in 
lines [2| [71 or [T4l then it completes its lockjO call. 

The abort () method. Suppose p executes a call to abortjO- Process p first determines 
whether it quit lockjO while busy-waiting on apply [i] in lineEJ and if so, p returns _L in lineHHJ If 
not, then p changes apply [i] to the value PRO in line 1191 to prevent itself from getting collected in 
future collect actions. In line 1201 process p determines whether it quit lockjO while busy- waiting 
on apply [i] in line [71 or I14[ or while busy-waiting on Syncl in line [HI If p quit while busy-waiting 
on apply [i] then clearly it is a pawn process, and if it quit while busy-waiting on Syncl then it is a 
queen process. 

If process p determines that it is a pawn then it attempts to remove itself from PawnSet by 
executing a PawnSet. abort (i, s) operation in line !211 where s was the sequence number returned in 
line[U If P has not been promoted yet, then the operation succeeds and p's corresponding element 
in PawnSet is changed to a value (ABORT, s), thus making sure that p can not be collected or 
promoted anymore. If p has already been promoted then the operation fails and p now knows that 
it is has been promoted, and assumes the role of a promoted pawn, and in line[22l p writes PAWN_P 
into Role[i] and returns the special value oo in line 1231 

If process p determines that it is queen L then it first attempts to swap a special value oo into 
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Syncl in line [26] by executing a Syncl.CAS(_L, oo) operation to indicate its desire to abort. If p is 
successful then p has determined that it is the first (among king L and itself) to exit, and therefore 
p performs the collect action by calling doCollectj () in line [29] Process p then makes a call to 
helpReleasej () in line [30] to help release lock L by synchronizing with king L . 

If p was unsuccessful at swapping value oo into Syncl then it knows the king L is executing 
release (), and king L will eventually perform the collect action. Then p has determined that it is 
the current owner of lock L, and returns the integer value stored in Syncl in line 1271 

Process p executes line [32] only if p successfully aborted earlier in its abort () call, and thus it 
deregisters itself from lock L by swapping (J_, J_) into apply [i] . Finally, in line [33] p returns _L to 
indicate a successful abort (i.e., a failed lockQ call). 

D.2 Analysis and Proofs of Correctness 

Let H be an arbitrary history of an algorithm that accesses an instance, L, of object ALockArray n , 
where the following safety conditions hold. 

Condition D.l. (a) No two lockjO calls are executed concurrently for the same i, where i 6 
{0,...,n-l}. ' 

(b) If a process p executes a successful lock,() call, then some process q eventually executes a 
release^) call where the invocation of release, () happens after the response o/lockjO 
(assuming the scheduler is such that q continues to make progress until its release, () call 
happens). 

(c) For every release^) call, there must exist a unique successful lock,() call that completed 
before the invocation of the release^) call. 

Then the following claims hold for history H. 

Lemma D.2. Methods releasej(j), abort, (), helpRelease^ () , doCollectj () , doPromotej () 

are wait-free. 

Proof. Follows from an inspection of these methods. □ 

Claim D.3. No two release^) calls where a shared memory step is pending, are executed con- 
currently for the same i, where i £ {0, . . . , n — 1}. 

Proof. Assume for the purpose of a contradiction that two processes are executing a call to 
release^) concurrently for the first time at time t. Then from Condition ID.lf b)-(c). it fol- 
lows that two successful calls to lock,() were executed before t. From condition ID. 1( a) it follows 
that the two successful lock,() calls did not overlap. Consider the first successful lockjO call 
executed by some process p. Since the lockjO call returned a non-_L value, the method did not 
return from line [18] Then p did not abort while busy-waiting in line [2] and thus apply[z] was set to 
a non-(_L, _L) value in line [2] during the first lock,() call. Let t' be the point in time when applyfi] 
was set to a non-(_L,±) value in line [2] We now show that the applyfi] ^ (-L,-L) m the duration 
between [t',t]. Suppose not, i.e., some process resets apply [i] to (J-,-L) during [t',t]. Now, apply [i] 
is reset to a (-L, -L) value only in line [32] during abort, () or in line 09] during release^). 

Case a - apply [z] reset to (_L, _L) in line [49] during release^). Then the last shared memory 
step of the release^) has been executed, and the call has ended for the purposes of the claim. 
Then the two release^) calls are not concurrent at t, a contradiction. 
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Case b - applyfz] reset to (JL,JL) in line [32] during abortjO- Since the two lockjO calls 
are not concurrent it follows that apply[i] 7^ (_L, _L) at the end of the first lockjO call, and thus 
apply[i] is reset to (_L, _L) in line [32] during the second successful lockjO call. Now consider the 
second successful lockjO call executed by some process q. Then q would repeatedly fail the 
apply[i].CAS((_L, _L), •) operation of line [2] and the only way q's lockjO call could finish, is if 
q aborts the busy- wait loop of line [2] In which case q executes abort j ( ) , and satisfies the if- 
condition of line [18] and return _L in line 1181 Then the second lockjO does not reset apply [i] in 
line [32] during abort jO - a contradiction. 

Since apply [i] 7^ (J-,-L) throughout [t',t], it then follows from the same argument of Case b, 
that the second lockjO call is unsuccessful, and thus a contradiction. □ 

From Claim HX3l and Condition ID. 1( a) it follows that no two calls to lock p () or release p () 
are executed concurrently for the same p, where p 6 {0, . . . , n — 1}. Then we can label the process 
executing a lock p () or release p () call, simply p, without loss of generality. We do so to make 
the rest of the proofs easier to follow. 

Helpful claims based on variable usage. 

Claim D.4. (a) Ro\e\p] is changed by process q, only if q = p. 

(b) Role[p] is unchanged during release„(). 

(c) Role[p] can be set to value KING, QUEEN or PAWN only whenp executes line\^during lock p (). 



(d) Role[p] is set to value PAWN_P only whenp executes line\^ during lock p () or whenp executes 
line [HI during abort p () . 

Proof. All claims follow from an inspection of the code. □ 

Claim D. 5. (a) The only operations on PawnSet are collected), promoteO, remove(i), 
removeOO; abort(/c,s) and reset() (in lines [55], EH \§J^ E3 HED and respectively) where 
A is a vector with values in {_L} U N ; and i, j, k S {0, 1, . . . , n — 1}, and s G N. 

(b) The i-th entry of PawnSet can be changed to (REG,s) = (l,s), where s € N, only when a 
process executes a PawnSet. collect (A) operation in line\5£& where A[i] = s. 

(c) The i-th entry of PawnSet can be changed to (PRO,s) = (2,s), where s G N, only when a 
process executes a PawnSet. promoteO operation in line\6h\ 

(d) The i-th entry of PawnSet can be changed to (ABORT, s) = (3,s), where s € N, only when a 
process executes a PawnSet. remove (i) , PawnSet. remove (j) or PawnSet. abort (k, s) operation 
in lines 61, \61\ or \21[ respectively. 

Proof. Part (jaj) follows from an inspection of the code. Parts fb|), (jcj) and ((d|) follow from Part (jaj) 
and the semantics of type AbortableProArray n . □ 

Claim D.6. Let s € N. 

(a) apply[p] is changed from (J-,-L) to a non-(_L,s) value only when process p executes a successful 
apply [p\. CAS ( (_L, _L), (REG, s)) operation in line\B 

(b) apply[p] is changed to value (REG,s) only when process p executes a successful ap- 
ply [p\. CAS ((_L, _L), (REG, s}) operation in line\M 
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(c) apply[p] is changed to a (_L, _L) value only when p executes a successful ap- 
ply [p], CAS ((PRO, s), (J_, _L)) operation either in line{3M or line 49 



Proof. Parts (jaj), (|b|) and (jcj) follow from an inspection of the code. □ 

Helpful Notations and Definitions. We now establish a notion of time for our history H. 
Let the i-th step in H occur at time i. Then every point in time during H is in N. 

Let tp denote the point in time immediately after process p has finished executing line i, and 
no process has taken a step since p has executed the last operation of line i (This operation can be 
the response of a method call made in line i). Since some private methods are invoked from more 
than one place in the code, the point in time t p , where i is a line in the method, does not refer to 
a unique point in time in history H. In those cases we make sure that it is clear from the context 
of the discussion, which point t p refers to. Let t l ~ denote the point in time when p is poised to 
execute line i, and no other process takes steps before p executes line i. 

Let p be an arbitrary process and s be an arbitrary integer. We say process p registers, when 
it executes a successful apply[p].CAS((_L, _L), (REG, s)) operation in line [TBI Process p captures and 
wins lock L when it returns from lock p () with a non-_L value. Process p is said to promote another 
process q if p executes a PawnSet.promoteO operation in line [65] that returns a value (q, s), where 
s £ N. A process p is said to be promoted at lock L, if some process q executes a PawnSet.promoteO 
operation that returns value (p, s), where s G N. 

Process p is said to hand over lock L to process q if it executes a successful CAS operation 
L.Syncl.CAS (J_, j) in line I37[ where q is the process that last increased Ctr from 1 to 2. Process p 
is said to have released lock L by executing a successful Ctr. CAS (1,0) operation in line [361 or by 
executing a successful Ctr. CAS (2,0) operation in line 1681 Process p either hands over, promotes 
a process, or releases lock L during a call to L.release p (j) where j is an arbitrary integer. A 
process ceases to own a lock either by releasing lock L or by promoting another process, or by 
handing over lock L to some other process. Process p is deregistered when p executes a successful 
apply [p]. CAS ( (PRO, s), (_L, _L)) operation in line [32] or [49] A process p is said to be not registered 
in PawnSet if the p-th entry of PawnSet is not value (REG, s), where s € N. The repeat-until loop 
starting at line [Hand ending at line [12] is called role-loop. 

In some of the proofs we use represent an execution using diagrams, and the legend for the 
symbols used in the diagrams is given in Figure [7] 

Releasers of lock and Cease-release events. 

A process p becomes a releaser of lock L at time t when 

(Rl) p increases Ctr to 1 (i.e., Ctr.incQ returns = KING) or 2 (i.e., Ctr.incO returns 1 = 
QUEEN), or when 

(R2) p is promoted at lock L by some process q . 

Claim D.7. (a) p executes a Ctr.CAS(l,0) operation only in line\36\ during release p (j). 

(b) p executes a Sync2.CAS(±,p) operation only in line{5M during p's call to helpRelease p () . 

(c) p executes a PawnSet.promoteO operation only in line\6£& during p's call to doPromote p () . 

(d) p executes a Ctr.CAS(2,0) operation only in line\6M during p's call to doPromote p () . 

Proof. All claims follows from an inspection of the code. □ 
We now define the following cease-release events with respect to p : 



31 



Atomic shared memory operation executed in line I. 



Method call m executed in line I. 



Operation in line £2 is executed only after the operation in line £\ . 



Predicate V is evaluated in line £. 

The next line executed is £\ if and only if V is true. 

The next line executed is £2 if and only if V is false. 



Predicate V is evaluated in line I. 

The next line executed is £\ if and only if V is true. 

The next line executed is £2 if and only if V is false and condition C is false. 
The next line executed is £3 if and only if V is false and condition C is true. 



Statement S holds after line l\ is executed and before line (.2 is executed. 



Helpful statement S to improve the readability of the figure. 



Operation op executed in line £ 

Figure 7: Legend for Figures [8] to [16] 
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<p p : p executes a successful Ctr.CAS(l,0) (at enduring release p (j)). 

T p : p executes a successful Sync2.CAS (_L,p) (at J^Sl during helpRelease p O). 

7r p : p promotes some process q (at during doPromote p O). 

9 p : p executes an operation Ctr.CAS(2,0) (at during doPromote p O). 

Process p ceases to be a releaser of lock L when one of p's cease-release events occurs. We say 
process p is a releaser of lock L at any point after it becomes a releaser and before it ceases to be 
a releaser. 



Claim D.8. (a) Method doCollect p () is called only by process p in lines \ 2^ and\ 

(b) Method helpRelease p () is called only by process p in lines \39l and \30l 

(c) Method doPromote p () is called only by process p in line [76] and in line EH (during 
helpRelease p () ). 

(d) If cease-release event 4> p occurs then p is executing release p (j). 

(e) If cease-release event r p occurs then p is executing helpRelease Q . 

(f) If cease-release event tt p or 8 p occurs then p is executing he lpRe leas e p () or doPromote p () . 

Proof. Parts (jaj), fb|) and (jcj) follow from an inspection of the code. By definition, cease-release 
event 4> p occurs when p executes a successful Ctr.CAS (1, 0) operation in line [36] during release p (j) , 
and thus (|d|) follows immediately. By definition, cease-release event r p occurs when p executes a 
successful Sync2.CAS(_L,p) in line [56] during helpRelease p () , and thus (jej) follows immediately. 
By definition, cease-release event tt p occurs only when p executes a PawnSet.promoteO operation 
that returns a non-(_L, _L) value in line 1651 and cease-release event 9 P occurs only when p executes 
a Ctr.CAS (2,0) operation in line [68] Then if cease-release event n p or 9 p occurs then p is executing 
doPromote p () . From (jcj), p could also call doPromote p () from line [62] during helpRelease (). 
Then if cease-release event tt p or 9 p occurs then p is executing doPromote p () or helpRelease p (). 
Thus, holds. □ 

Claim D.9. Consider p's k-th passage, where k 6 N. Note that s = k. If Role[p] = PAWINLP 

at some point in time t during p's call to lock p (), then some process q promoted p at Jj^S and p 
became releaser of L by condition (R2) at t. 



Proof. From Claim IIX4l ljd"j) . p changes Role[p] to PAWIXLP only in line [9] or line 1221 

Case a - p changed Role[p] to PAWINLP in line [22] Then p's call to PawnSet. abort (p, s) 
returned false in line [21] From the semantics of the AbortableProArray n object, it follows that 
the p-th entry of PawnSet was set to value (PRO, s) = (2, s). From Claim lrX5Tlc| . the p-th entry of 
PawnSet is set to value (PRO, s) only when a PawnSet.promoteO operation returns (p, s) in line 1651 
Then some process q promoted p at and p became a releaser of L by condition (R2) at < t. 

Case b - p changed Role[p] to PAWINLP in line [9] Then p broke out of the spin loop of line [2] 
and thus apply [p] = (REG, s) / (PRO, s) at Since p satisfied the if-condition of line it follows 

that apply[p] = (PRO,s) at M Since p does not change apply[p] to value (PRO,s) during [Jp, 
it follows that some other process changed applyfp] to value (PRO,s). Now, applyfp] is changed to 
value (PRO,s) by some other process (say q) only in line 1701 and thus, from the code structure, q 
also executed a PawnSet.promoteO operation that returned (p,s) in line 1651 Then q promoted p 
at and p became a releaser of L by condition (R2) at J^S < □ 
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Claim D.10. Consider p's k-th passage, where k e N. If t € { [pKfl, ffKfl; 

| ; then cease-release event <j) p does not occur before time t. 

Proof. By definition, cease-release event 4> p occurs when p executes a successful Ctr.CAS(l,0) op- 
eration in line[36j From Claim lD78l fd|) cease-release event 4> p occurs only during release p (j). 

Case a - t £ [§^K^r^]: Then p is executing abort p () and has not yet executed a call to 
release p (). Since cease-release event 4> p can occur only during release p (), cease-release event 
4> p did not occur before time t. 

Case b - t £ JP^: Then p must have failed the if-condition of line 1361 an d thus p 

executed an unsuccessful Ctr.CAS(l,0) operation in line [361 an d cease-release event 4> p did not 
occur before time t. 

Case c- t£{ [ipKfl, }: From Claim EEO Role[p] e {QUEEN, PAWN.P} at 

t. Since Role[p] is unchanged during release p () (Claim lD.4l fb"j)). it follows that Role[p] ^ KING at 
Then p fails the if-condition of line 1351 and does not execute line [36] and thus cease-release 
i>r, did not occur before time t. □ 
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The proof of the following claim has been moved to Appendix [F] since the proof is long and 
straight forward. 

Claim D.ll. The value of Role[p] at various points in time during p's k-th passage, where k £ N, 
is as follows. 
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Claim D.12. Consider p's k-th passage, where k £ N. 

(a) If process p calls helpRelease p () or doPromote p () during abort p () then it does not call 
release p (j) . 

(b) Process p calls helpRelease p () at most once. 

(c) Process p calls doPromote p () at most once. 

Proof. Proof of (jaj): The following observations follow from an inspection of the code. If 
p executes doPromote p () during abort p (), then it does so during a call to helpRelease p () in 
line[62j If p executes helpRelease () during abort p (), then it does so by executing line[30l Then 
p calls helpRelease^ () or doPromote p () during abort p () in line 1301 and goes on to return value _L 
in line[33j Then p's call to lock p () returns value _L and p does not call release p () (follows from 
conditions [b] and [d} . 
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Proof of ([b]): From Part (jaj), if helpRelease p () is executed during abort p () then 
release p (j) is not executed. Then to prove our claim we need to show that helpRelease p () is 
called at most once during abort p () and release^ (j) , respectively. From Claim lD78l fb]) . method 
helpRelease p () is called by p only in lines I39] 1431 and 1301 Since helpRelease p () is called only once 
during abort p () (specifically in line l30j) . it follows immediately that p executes helpRelease p () at 

most once during abort p (). From ClaimETQ Ro\e\p] G {KING, QUEEN, PAWISLP} at Since 
Role[p] is unchanged during release p () (Claim [D.4t |b])). it follows that p satisfies exactly one of 
the if-conditions of lines [351 |4"2] and 1431 an d thus p does not execute both lines [39] and 031 Then p 
executes helpRelease p () at most once during release p (j). 

Proof of (jcj): From Part (jaj), if doPromote p () is executed during abort p () then release p (j) 
is not executed. Then to prove our claim we need to show that doPromote p () is called at most 
once during abort p () and release p (j) , respectively. From Claim IrXBT jcj) , method doPromote p () 
is called by p only in line 1461 and in line [62] (during helpRelease p ()). 

Case a - p called doPromote p () in line [62] (during helpRelease p ()). Then p is executing 
helpRelease (). From Claim HXBflbj), method helpRel ease () is called by p only in lines 1391 [431 
and 1301 Then p called helpRelease p () either in line I39j [431 or [30l 

Case a(i) - p called helpRelease () in line[39]or03] (during release p (j)). Then p is executing 
release p (), and since p called helpRelease () in lines 1391 or 1431 p satisfied the if-conditions of 

lines [35] or 02] and thus Ro\e[p] = KING at or Ro\e[p] = QUEEN at respectively. Since 

Role[p] is unchanged during release p () (Claim [ED®), it follows that Role[p] G {KING, QUEEN} 
during release p (). Then p fails the if-condition of line 05] and does not execute doPromote p () in 
line [36] Hence, p executes doPromote p () at most once during release p (). 

Case a(ii) - p called helpRelease p () in line 1301 Then p is executing abort p () and it goes 
on to return value _L in line [33] Then p's call to lock p () returns value _L and p does not call 
release p (j) (follows from conditions [b] and [d]) . Hence, p executes doPromote p () at most once 
during abort p () . 

Case b - p called doPromote p () in line 06] Then p is executing helpRelease p () and p satisfied 

the if-condition of lines 05] and thus Role[p] = PAWN_P at J^~. Since Role[p] is unchanged during 
release p () (Claim [ED®), it follows that Ro\e\p] = PAWN_P during release p (). Then p failed 
the if-condition of lines [35] and 02] and p did not execute helpRelease^ () in lines 1391 and 1431 Hence, 
p executes doPromote p () at most once during release p (). □ 

Claim D.13. Consider p's k-th passage, where k € N. Let t be a point in time at which either p 
is poised to execute release p (j) ; or t E { [f^Kf^, [f^Kf^, [f^f 5 ! , f^lf 3 ", f% 
fp . |3 ./P }. Then 

(a) none of p's cease-release events have occurred before time t, and 

(b) p is a releaser of lock L at time t 

Proof. Proof of (jaj): First note that if t G [ep^cfrn then p is executing doCollect () . From 
Claim Elljaj), p calls doCollect () only in lines [29] and [38] Then if t G then t G [Jj§h 

or t G [JpK Therefore, assume now t G or t G 

Case a - t G If t G then from a code inspection, p 

is executing abort p () and p did not execute a call to doPromote p () or helpRelease p () before 

time t. If t G [^-^~, then p is executing release p (j) and then from a code inspection and 
Claim ID.12f [aj) it follows that p did not execute a call to doPromote p () or helpRelease p () before 
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time t. Then from Claims ID.8l f[e]) and ID.8l f|fj) it follows that events r p , tt p and P did not occur 
before time t. Since t G [^pK^r^] or t G [^^~ , ^\ , it follows from Claim ID. 101 that cease-release 



event 4> p did not occur before time t. 



Case b - t £ { [^FKIFH } : Then p is executing helpRelease p () . Then from 

Claim HX8l |b|) it follows that p is executing a call to helpRelease p () in line I39[l43l or 1301 Then from 
Claim |DT0] it follows that cease-release event 4> p did not occur before time t. From Claim ID.12l|b|) . 
it follows that this is p's only call to helpRelease p () . From Claim [jXHtjc] ) . p calls doPromote p () 
only in line d6] and in line [62] (during helpRelease p () ). Since p has not yet executed line 06] and 
this is the only call to helpRelease p () , p has not called doPromote p () before time t. Then from 
Claim ID.8t ffj) it follows that events tt p and 6 P did not occur before time t. By definition, cease- 



release event r p occurs when p executes a successful Sync2.CAS(_L,p) in line[56j lit = then 

clearly cease-release event t p did not occur before time t. If t G [^p^~>^PH> then p satisfied the 
if-condition of line 1561 and thus p executed an unsuccessful Sync2.CAS(_L,p) operation in line I56[ 
and thus cease-release event r„ did not occur before time t. 

Case c - t G { Jjpl-, }: Then p is executing doPromote p () . From Claim EHJcj) , 

it follows that this is the only call to doPromote p (). By definition, cease-release event 9 P occurs 
only when p executes a Ctr.CAS(2, 0) operation in line [68] of doPromote p () . Event 9 p did not occur 
before time t since t < Jp] an d this is p's only call to doPromote p (). By definition, cease-release 
event tt p occurs only when p executes a PawnSet. promote () operation that returns a non-(_L,_L) 
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value in line [65] of doPromote p () . If t = Bp", then cease-release event ir p did not occur before 
time t since < ( an d since this is p's only call to doPromote p ()). If t G [^K^r^~], then 

p satisfied the if-condition of line 1651 and thus p's PawnSet.promoteO operation returned value 
(_L,_L), and thus cease-release event n p did not occur before time t. Since p calls doPromote p () 
only in line [46] and line [62] (during helpRelease p ()), p is executing line [46] (39] [43] or [30] Then 
from Claim [D. 101 it follows that cease-release event 4> p did not occur before time t. 

We now show that cease-release event r p did not occur before time t thus completing the proof. 

Subcase c(i) - p called doPromote p () during helpRelease p () : Then p satisfied the if- 
condition of line [56] and thus p executed an unsuccessful Sync2.CAS (_L,p) operation in line [56] 
and cease-release event r p did not occur before time t. 

Subcase c(ii) - p called doPromote p () in line[M] From ClaimETT] Ro\e[p] G PAWINLP at . 
Since Role[p] is unchanged during release p () (Claim [TX4l[b]) ). it follows that Role[p] = PAWN_P 
at Jpl- and . Then p fails the if-conditions of lines 1351 and 1421 and does not execute a call to 
helpRelease p () before time t. Then from Claim lD78t fej) it follows that cease-release event r p did 
not occur before time t. 

Proof of ([b]): From Part (jaj), p does not cease to be releaser of L before t. Therefore, to prove 
our claim we need to show that p becomes a releaser of L at some point t' < t. We first show that 
Ro\e[p] G { KING, QUEEN, PAWN.P } at time t. Let t' be the point when p is poised to execute 
release p (j). From the inspection of the various points in time chosen for t (including i!^", but 
excluding t') and the table in Claim ETT] it follows that Role[p] G { KING, QUEEN, PAWN.P } at 
time t (including , but excluding t'). Clearly Role[p] is unchanged during [t', ^^~]- Then the 

value of Role[p] at t' is the same as that at Jp~, i.e., Role[p] G { KING, QUEEN, PAWN.P }. 

Case a - Rolefp] G {KING, QUEEN} at time t: From Claim Eljcj) , Ro\e[p] is set to KING or 
QUEEN only when p executes line [5] Then p changed Role[p] to KING or QUEEN at and thus p 

became a releaser of lock L by condition (Rl) at t' < t. 

Case b - Role[p] = PAWN_P at time t: From Claim ID. 91 it follows that some process q 
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promoted p at ip^l an( \ p became a releaser of L by condition (R2) at ip^= t' < t. □ 

Claim D.14. Consider p's k-th passage, where k £ N. Tjf any of process p's cease-release events 
occurs at time t then p ceases to be the releaser of lock L at time t. 

Proof. To prove our claim we need to show that p is a releaser of L immediately before time t, since 
by definition p ceases to be a releaser of L when any of p's cease-release events occurs. By definition, 
cease-release event (j) p occurs whenp executes a successful Ctr.CAS(l,0) operation in lineEU cease- 
release event r v occurs when p executes a successful Sync2.CAS(±,p) in lineEU cease-release event 
TT p occurs only when p executes a PawnSet. promote () operation that returns a non-{_L, JL) value 
in line 165} cease-release event 6 P occurs only when p executes a Ctr.CAS(2,0) operation in line 1681 
From Claim lrTT3t| b]) . p is a releaser of L at Jjp^~, ^r*K and JjpJ- . Hence, the claim follows. □ 

We say a process has write- access to objects Syncl and Sync2, respectively, if the process 
can write a value to Syncl and Sync2, respectively. We say a process has registration- access 
to object PawnSet, if the process can execute an operation on PawnSet that can write values 
in {(a, b)\a € {0, 1, 2} = {0, REG, PRO} , b G N} to some entry of PawnSet. We say a process has 
deregistration- access to object PawnSet, if the process can execute an operation on PawnSet that 
can write value (ABORT, s) = (3, s), where s € N, to some entry of PawnSet. Object PawnSet is 
said to be candidate- empty if no entry of PawnSet has value (REG, •} or (PRO, •). 

Claim D.15. Only releasers of L have write-access to Syncl, Sync2 and registration- access to 
PawnSet. 

Proof. The following observations follow from an inspection of the code. A value can be written to 
Syncl only in lines 1261 1371 and [58l A value can be written to Sync2 only in lines 1561 and 1601 From the 
semantics of the AbortableProArray n object, only operations collect (), promote (), and reset () 
can write values in {(a, b)\a € {0, REG, PRO} = {0, 1, 2} ,b € N} to PawnSet. From Claim ESfej) , 
the operations collect (), promote (), and reset () are executed on PawnSet only in lines [55j |65j 
and [671 respectively. 

Suppose an arbitrary process p writes a value to Syncl or Sync2, or a value in 
{(a,6)|a g {0,1,2} ,b G N} to an entry of PawnSet. From Claim iDlMbl) . p is a releaser of L 
at |p-, JED-, Jp- and JSS1- Henc6) the claim fo nows. □ 

Claim D.16. The i-entry of PawnSet can be changed only by process i or a releaser of L. 

Proof. The values that can be written to PawnSet are in {(a, b)\a £ {0,1,2,3} ,b £ N}. A pro- 
cess that can write values in {(a,b)\a 6 {0,1,2} ,b £ N} to any entry of PawnSet is said to have 
registration-access to PawnSet. From Claim [D.15l it follows that only a releaser of L has registration- 
access to PawnSet, therefore only a releaser of L can write values in {{a, b)\a € {0, 1, 2} , b € N} to 
the i-th entry of PawnSet. From Claim ITX5l fdl) the value (ABORT, s) = (3,s), where s € N, can 
be written to the z-th entry of PawnSet only when a process executes a remove (i) , remove (z) or 
PawnSet. abort (i, s) operation in line 1641 IHTI or \2l\ respectively. From Claim lD.13tlb|) . it follows 
that a process executing lines [Ml an d [61] is a releaser of L Since a Pawn Set. abort (i, s) operation 
in line[2TJis executed only by process i, our claim follows. □ 

Claim D.17. Sync2 is changed to a non-1, value only by a releaser of L (say r) in line\56\ which 
triggers the cease-release event r r . 
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Proof. By definition, cease-release event r p occurs when p executes a successful Sync2.CAS(±,p) in 
line [56l From a code inspection, Sync2 is changed to a non-± value only when some process (say r) 
executes a successful Sync2.CAS(_L, r) operation in line 1561 From Claim ID, 151 it follows that Sync2 
is changed only by a releaser of L. Then r is a releaser of L when it changes Sync2 to a non-_L value 
in line [56] and doing so triggers the cease-release event r r . □ 

Claim D.18. A PawnSet. promote () operation is executed only by a releaser of L (say r), and if 
the value returned is non-(_L,_L) the cease-release event ir r is triggered. 

Proof. By definition, cease-release event tt p occurs only when p executes a PawnSet. promote () 
operation that returns a non-(_L, _L) value in line 1651 From a code inspection, a PawnSet. promote () 
operation is executed only when some process (say r) executes line [56] From Claim lD.151 it follows 
that PawnSet is changed only by a releaser of L. Then r is a releaser of L when it executes a 
PawnSet.promoteO operation, and if the operation returns a non-(_L,_L) value then the cease- 
release event ir r is triggered. □ 

Claim D.19. During an execution of doPromote p () exactly one of the events ir p and 9 p occurs. 

Proof. By definition, cease-release event ir p occurs whenp executes a PawnSet.promoteO operation 
in line [65] that returns a non-(_L,_L) value, and cease-release event 6 P occurs when p executes a 
Ctr.CAS(2,0) operation in line [68] during doPromote p () . 

Case a - the PawnSet.promoteO operation in line [65] returns a non-(_L,±) value, and thus 
cease-release event ir p occurs: Then p fails the if-condition of line [66] and line [68] is not executed. 
Therefore, cease-release event 9 p does not occur. 

Case b - the PawnSet.promoteO operation in line 1651 returns (_L,_L), and thus cease-release 
event n p does not occur: Then p satisfies the if-condition of line 1661 and executes a Ctr.CAS(2,0) 
operation in line [68] Hence, cease-release event 6 P occurs. □ 

Claim D.20. During an execution of helpRelease p () exactly one of the events T p ,ir p and 6 p 
occurs. 

Proof. By Claim IDTf] events ir p and 9 p can only occur during p's call to doPromote p O, and cease- 
release event r p occurs when p executes a successful Sync2.CAS (±,p) operation in line [56] 

Case a - p executes a successful Sync2.CAS(±,p) operation in line [SSI and thus cease-release 
event t p occurs: Then p fails the if-condition of line [56l and returns immediately from its call to 
helpReleasej () . Therefore, events 7r p and 9 p do not occur. 

Case b - p executes an unsuccessful Sync2.CAS(_L,p) operation in line 1561 and thus cease- 
release event t p does not occur. Then p satisfies the if-condition of line [56] and calls doPromote p O 
in line [62] From Claim ID. 19) exactly one of the events ir p and 6 P occurs during p's call to 
doPromote p () . □ 

Claim D.21. The value of Ctr can change only when a Ctr.incO, Ctr.CAS(2,0) or Ctr.CAS(l,0) 

operation is executed in lines\^ \UB\ or\Sb\ 

Proof. From the semantics of the RCAScounter2 object, if Ctr is increased to value i by a Ctr.incO 
operation, then its value was i — 1 immediately before the operation was executed. Then all claims 
follow from an inspection of the code. □ 

Claim D.22. If the value of Ctr changes, it either increases by 1 or decreases to 0. Moreover its 
values are in {0, 1, 2}. 
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Proof. From the semantics of the RCAScounter2 object, a Ctr.incQ operation changes the value 
of Ctr from i to i + 1 only if i 6 {0, 1}. From Claims lD.211 the value of Ctr can change only when 
a Ctr.incQ, Ctr.CAS(2,0) or Ctr.CAS(l,0) operation is executed (in lines l5l [681 or |36|) . Then it 
follows that the values of Ctr are in{0, 1,2}. It also follows that the value of Ctr either changes 
from to 1 and back to 0, or it changes from to 1 to 2 and back to 0. □ 

Ctr-Cycle Interval T. Let T = [t s , t e ) be a time interval where t s is a point when Ctr is and 
t e is the next point in time when Ctr is decreased to 0. For i £ {0, 1, 2} let I{ = {t £ TjCtr = i at t} 
and let time I~ = min(/j) and time if = max(/j). From Claim lD.221 it follows immediately that 
during T the set € {0, 1,2}, forms an interval [J~, if], and I2 = if and only if Ctr is never 
increased to 2 during T. Moreover, t s = Iq and Iq is immediately followed by I\ (i.e., min(/i) = 
max(Jo) + 1)- If I2 7^ then I2 follows immediately after I\. The Ctr-cycle interval T ends either 
at time if if I2 = 0, or at time if if I2 7^ 0. 

Then it also follows that exactly one process changes Ctr from to 1 during T, and it does so at 
time 7j~ . Let K, be the process that increases Ctr to 1 at time I-f . And if I2 ^ then exactly one 
process changes Ctr from 1 to 2 during T, and it does so at time I^. If I2 7^ let Q be the process 
that increases Ctr to 2 at time Let R(t) denote the set of processes that are the releasers of 
lock L at time t G T. 

Claim D.23. If R(Iq) = and at Iq , Syncl = Sync2 = _L and PawnSet is candidate- empty, then 
the following holds: 

(a) Vt g / : R(t) = and throughout Iq, Syncl = Sync2 = _L and PawnSet is candidate- empty. 

(b) R(Ii) = {/C} and at time Syncl = Sync2 = _L and PawnSet is candidate- empty. 

(c) fC executes lines of code o/lock^O starting with line\^as depicted in Figure^ (A legend for 
the figure is given in Figure ) 



( Apply[E].CAS((_L, 1), (REG, s)) ) 



K returns 00 



2 

false 5 6 12 13 16 17 

true > • — >• — — >• — >m — >• 



\ Role[£] = KING = o\ 

Figure 8: /C's call to lock^O 

(d) fC's call to lock^O returns oo and Role[/C] = KING throughout [Jj^J, $$\- 

(e) fC executes a Ctr. CAS (1,0) operation in line\3^ during T , and K, does not change Syncl, Sync2 
or PawnSet throughout [/•[" , e*pj. 

(f) Vtgji : R(t) = {K.}. 

(g) Throughout I\, Syncl = Sync2 = _L and PawnSet is candidate- empty. 

Proof. Proof of (jaj): Consider the claim R{t) = where t £ Iq. Since R(Iq) = holds by 
assumption, the claim holds at t = Iq . For the purpose of a contradiction assume the claim fails 
to hold for the first time at some point t' during Iq. Then some process p becomes a releaser of 
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lock L at time t' . Process p cannot become a releaser of L by p increasing Ctr to 1 or 2 (condition 
(Rl)) at time t' , since Ctr = throughout Iq. Therefore, assume it becomes a releaser of L when 
some process q promotes p (condition (R2)) at t'. By Claim lD.141 q ceases to be a releaser of lock 
L at i! . This is a contradiction to our assumption that p is the first process during Iq to become a 
releaser of L. 

By assumption the variables Syncl,Sync2 and PawnSet are at their initial value at Iq . Since 
the values of these variables are only changed by a releaser of lock L (by Claim ID. 15|) and for all 
t € Io, R(t) = 0, it follows that the variables are unchanged throughout io- 

Proof of db]) : At time J-f Ctr is increased from to 1, and thus the only operation executed is a 
Ctr.inc () operation by process tC. Then K, becomes a releaser of lock L at time /£" by condition (Rl). 
Since for all t G I , R(t) = (Part (jaj)), it follows that R(I{) = {£}. Since Syncl = Sync2 = _L 
and PawnSet is candidate-empty throughout Io (Part (jaj)), and the only operation at time /{~ is the 
Ctr.inc () operation, it follows that Syncl = Sync2 = _L and PawnSet is candidate-empty at time 

Ii ■ 

Proof of (|cj) and (Jd|): Since /C is the process that increased Ctr from to 1 at time / x , and 
since /C can increase Ctr only by executing a Ctr.inc () operation in line [5] (by Claim ID.2ip JC set 
Role[/C] = = KING at i^. Then from the code structure, fC does not execute lines HE] and does 
not repeat the role- loop, and does not busy- wait in the spin loop of line EJ instead /C proceeds 
to execute lines [16] - [T7] and returns value oo in line [TTJ Since /C does not change Role[/C] during 
[fl,JJPi, Role[/C] = KING throughout [%$\. 

Proof of (jej): Since /C is the process that increased Ctr from to 1 at time JJ~ , and since 
K, can increase Ctr only by executing a Ctr.inc () operation in line [5] (by Claim ID.21j) K, set 
Role[/C] = = KING at JP. From Part ((dj), K, returns from lock^O with value oo in line I17| and 
thus /C consequently calls release^ (j) (follows from conditions (jbj) and (jd}). Note that fC has 
not executed any operations on Syncl, Sync2 and PawnSet in the process. Then Role[/C] = KING 



at cjc" and thus p satisfies the if-condition of line [35] and executes the Ctr. CAS (1,0) operation 
in line [36] during T without having executed any operations on Syncl, Sync2 and PawnSet in the 
process. Thus JC did not change Syncl, Sync2 or PawnSet during [I^,t^\. 

Proof of ([J): Since R(Ii) = {fC} (Part (Jb])), to prove our claim we need to show that during 
I\ K, does not cease to be a releaser and no process becomes a releaser. Suppose not, i.e., the claim 
R(t) = {/C} fails to hold for the first time at some point t' in I\. 

Case a - Process /C ceases to be a releaser of L at t': By definition, cease-release event ^K. 
occurs when /C executes a successful Ctr.CAS(l,0) operation in line[36j From Part (jej), /C executes 
a Ctr. CAS (1,0) operation in line [36] If K, executes a successful Ctr. CAS (1,0) operation in line [361 
then, by definition, cease-release event cp/c occurs and by Claim ID. 141 /C ceases to be the releaser of 
L. Thus, t' = JjjP^and Ctr changes to value of at t' . But since t' E I\ and Ctr = 1 throughout I\, we 
have a contradiction. If K, executes an unsuccessful Ctr.CASQ, 0) operation in line 1361 then Ctr ^ 1 
at JpK Since p did not cease to a releaser at JjjP", < it '. Since If = JjjP < ^ < jj < J+ and 



Ctr = 1 throughout I\, Ctr = 1 at , and thus we have a contradiction. 

Case b - Some process q becomes a releaser of L at t': Since Ctr is not increased during 
Ji, it follows from conditions (Rl) and (R2) that some process r promoted q at time t' . Then 
by definition, event ir r occurs at t', and thus from Claim ID.14I it follows that r is a releaser of L 
immediately before it '. Since JC is the only releaser immediately before t', r = Kt. Then cease-release 
event ir/c occurred at it and K, ceases to be a releaser at t'. As was shown in Case a, this leads to 
a contradiction. 

Proof of (jgj): At time 1^ the claim Syncl = Sync2 = _L and PawnSet is candidate-empty 
holds by Part (jb]). Suppose some process p changes Sync2 or Syncl or PawnSet for the first time 
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at some point t 1 during I\. From Claim [D. 151 it follows that p is a releaser of lock L at time t'. 
Since for all t £ 1%, R(t) = {/C} (Part (Jfj)), it follows that p = /C. From Part (jej), /C does not change 
any of the variables before the point when it executes a Ctr.CAS(l,0) operation in line [361 i- e -> 



"ic~ < ^ ^ executes a successful Ctr.CAS(l,0) operation in line 1361 then the interval 1% ends 
and clearly t' ^ 1%, hence a contradiction. If K, executes an unsuccessful Ctr.CAS(l,0) operation in 
line [361 then Ctr ^ 1 at JpK Since If = if - < JjjP" < i' < and Ctr = 1 throughout h, we 
have a contradiction. □ 

Claim D.24. If I2 ^ and R(Iq) = and at Iq , Syncl = Sync2 = i_ and PawnSet is candidate- 
empty, then the following claims hold: 

(a) R{I 2 ) = {/C, Q} and at time I 2 , Syncl = Sync2 = _L and PawnSet is candidate- empty. 

(b) K, and Q are the first two releasers of L. 

(c) During (J^T, I 2 ] a process can become a releaser of L only if it gets promoted by a releaser of 
L 



(d) IfJC takes enough steps, JC executes lines of code o/release/c () starting with line\3J^as depicted 
in Figured 

(e) K, executes an unsuccessful Ctr.CAS(l,0) operation in line{3(^ and calls helpRelease^ () in 
line \M such that I 2 < < . 

(f) If K and Q take enough steps, Q finishes lockgO during T. 

(g) If K, and Q take enough steps, Q executes lines of code o/lockgO starting with UnelM as 
depicted in Figure [70l 



(h) If Q calls releaseg() ; it executes lines of code o/releasegO starting with line 34 as depicted 
in Figure [771 



Q calls helpReleaseg () either in line\3Q or in line \^3\ after time I 2 ■ 



(ctr.CAS(0.~l)) 
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(Syncl.CAS(±, j5) 
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doCollectx; O 



Figure 9: /C's call to release*; (j) 

Proof. Proof of (jaj) and ([bj): Since Q is the process that increases Ctr from 1 to 2 at time I 2 , 
and since Q can increase Ctr only by executing a Ctr.incQ operation in line [5] (by Claim |P.2ip 
Q becomes a releaser of lock L by condition (Rl) at I 2 = ig. Since for all tE.Ii, R(t) = {K} 
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(Apply[Q].CAS((±,-L), (REG, a))) (Syncl.ReadQ ^ ±) 

j Q returns a non-_L value 



2 -t alse r. a 10 1Q * false 
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<?X true >« A >m >• >• kV true >m >• C s y nc | CAS ^^)) 
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Q returns a non-_L value 



I helpReleaseg () I | doCollectg ()| 

Figure 10: Q's call to lockgQ 
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J helpReleaseg C) J 

Figure 11: Q's call to releasegO 



(Claim EHH), it follows that #(I 2 ~) = {AC, Q}. By claim EHjg), throughout I h Syncl = 
Sync2 = J_ and PawnSet is candidate-empty, and since the only operation executed at time 1% is 
Ctr.incO, it follows that at time Syncl = Sync2 = _L and PawnSet is candidate-empty. Hence 
Part (Jb]) holds. Clearly AC and Q are the first two releasers of L, hence Part fb|) holds. 

Proof of (jcj): From conditions (Rl) and (R2), a process can become a releaser of L either by 
increasing Ctr to 1 or 2 or by getting promoted. Since Ctr is not increased during (ZJ" , I^] , it follows 
that during (J^" ' \ a process becomes a releaser of L only if it gets promoted. By definition, a 
process can be promoted only when a PawnSet.promoteO operation is executed in line [65] and from 
Claim ID. 181 only a releaser of L can execute this operation. Then during (J^T, l£\ a process becomes 
a releaser of L only if it gets promoted by a releaser of L. 

Proof of ((dj) and (jej): From Claim lD?23l |el). AC executes the Ctr. CAS (1, 0) operation in linel36l 
during T. If AC's Ctr. CAS (1,0) operation is successful then the value of Ctr decreases from 1 to 
and the Ctr-cycle interval T ends and thus I2 = 0, which is a contradiction to our assumption that 
I2 7^ 0. Then AC's Ctr. CAS (1,0) operation is unsuccessful. 

Since AC executes an unsuccessful Ctr. CAS (1,0) operation in line Ell AC satisfies the if-condition 
of line [36l executes lines [3711381 and calls helpRelease^ () in linel39l and then executes lines 14*911501 

Since AC executes an unsuccessful Ctr. CAS (1,0) operation in line [361 it follows that Ctr was 
changed from 1 to 2 at time £T (by definition), and thus < cjjp Since < ^21, it follows that 

r < iP<pi 

Proof of @, (jgj) and ([h]): Since Q is the process that increases Ctr from 1 to 2 at time 
and since Q can increase Ctr only by executing a Ctr.incO operation in line [5] (by Claim ID. 2ip Q 
set Role[AC] = 1 = QUEEN at J§ = 2^~. Then from the code structure, Q does not execute lines UE\ 
and does not repeat the role- loop, instead, it proceeds to line [13] and then proceeds to busy- wait 
in the spin loop of line [TH Then Q does not finish lockgO only if it spins indefinitely in line [TH 
and does not receive a signal to abort. 

For the purpose of a contradiction assume that Q does not finish lockgO. Then Q reads the 
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value _L from Syncl in line[T3]indennitely. From Part (jej) it follows that K, executes a Syncl.CAS(_L, j) 
operation in line [37] during (1%, I^]- Since Syncl = _L at time 1% (Part (jS$), and only a releaser can 
change Syncl (Claim [D. 15|) . and Q is busy- waiting in line 1141 it follows that the only other releaser, 
/C, executed a successful Syncl. CAS (_L, j) operation in line l37l during [I^^t] an< ^ changed Syncl 
to a non-_L value. Then for Q to read _L from Syncl in line [T3] indefinitely, some process must reset 
Syncl to _L before Q reads Syncl again. 

Case a - K, resets Syncl in line [58] before Q reads Syncl again: For K. to reset Syncl in line [58] 
K, must satisfy the if-condition of line 1561 and thus K must execute an unsuccessful Sync2.CAS(_L, K.) 
operation in line [56] Since Sync2 = _L at time (Part (jaj), and only a releaser can change Sync2 
(Claim [D. 15P . and Q is busy- waiting in line (H] it follows that Sync2 = _L at ■ Thus /C's 
Sync2.CAS (_L, /C) operation in line [56] is successful and we get a contradiction. 

Case b - some other process becomes a releaser and resets Syncl before Q reads Syncl again: 
From Part (jcj) it follows that during (I^ ,1%] a process can become a releaser of L only if it is 
promoted (by condition (R2)). Since a process is promoted only by a releaser of L and /C is the 
only other releaser of L apart from Q, it follows that /C promotes some process before Q reads Syncl 
again. As argued in Case a, K, executes a successful Sync2.CAS(_L, /C) operation in line [56] Then 
from the code structure, /C does not call doPromote^O in line [62] and thus K, does not promote 
any process. Hence, we have a contradiction. 

Proof of (E]): Since Q is the process that increases Ctr from 1 to 2 at time and since 
Q can increase Ctr only by executing a Ctr.incO operation in line [5] (by Claim ID.21 j) Q set 
Role[/C] = 1 = QUEEN at i^. Then from the code structure, Q does not execute lines [7J9] and does 
not repeat the role-loopp; instead, it proceeds to line [T3] and then proceeds to busy- wait in the spin 
loop of line [TU 

Case a - Q does not receive a signal to abort while busy- waiting in line HU From Part ([fj), 
Q does not busy- wait indefinitely in line 1141 and eventually breaks out. Since Q breaks out of the 
spin loop of line [14] it reads non-_L from Syncl and then from the code structure it follows that Q 
goes on to return that non-± value in line [TTJ Consequently Q calls releaseg(j) (follows from 
conditions [b] and [d]). Consider Q's call to releaseg(j'). Since Q last changed Role[Q] only in 
line El Role[Q] = QUEEN at JpK Since Role[Q] is unchanged during releasegQ (Claim HHP), 
it follows that Role[Q] = QUEEN throughout releasegO. Then from the code structure it follows 
that Q executes only lines 13311351 142H451 and [49][5Q] Then Q calls helpRelease Q () only in line SHI 
and since 1% = i§ < our claim holds. 

Case b - Q receives a signal to abort while busy-waiting in lineO Then Q calls abortgO, 
and from the code structure Q executes lines [T8H20] and then line[26] If Q fails the Syncl. CAS (_L, oo) 
operation of line 126] then Syncl ^ J- at cg - ^. From Claim ID. 151 only a releasers of L can change 
Syncl to a non-_L value, and since /C and Q are the only releasers of L, it follows that fC changed 
Syncl to a non-_L value. Then Q satisfies the if-condition of line [26] and returns the non-_L value 
written by /C to Syncl in line 1271 Consequently Q calls releaseg(j) (follows from conditions [b] 
and [d| , and as argued in Case a, Q executes only lines [311135] li"2"H4"5l and l4"9H50] and Q calls 
helpReleaseQ () only in line S3] Since 1^ = ^g < ^g , our claim holds. 

If Q's Syncl. CAS (_L, oo) operation is successful, then Q goes on to call doCollectg () in line 129] 
calls helpReleaseg () in line 1301 then executes lines 1321133] and finally returns _L in line [33] Since 
1 2 = i?j < i?p> our claim holds. □ 

Define A to be the first point in time when Sync2 is changed to a non-_L value, and if 
Sync2 is never changed to non-_L then A = oo. Define 7 to be the first point in time when a 
PawnSet.promoteO operation is executed, and if a PawnSet.promoteO operation is never executed 
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then 7 = oo. From Claims Elljej) and EH UD, both K. and Q execute helpRel ease^O and 
helpReleaseg () , respectively, after time Let A € {/C, Q} be the first process among them to 

1—1 I r /?i I F /? I 

execute line [56l and let B G {/C, Q} — {^4} be the other process, i.e., c^p < Bjfpl. 

Claim D.25. If I2 ^ and R(Iq) = and at Iq , Syncl = Sync2 = _L and PawnSet is candidate- 
empty, then the following claims hold: 

(a) I2 < A = and for all t £ [1% , A), R(t) = {/C, Q} and Sync2 = _L throughout [1% , A), and 
cease-release event tj± occurs at A. 

(b) If K, and Q take enough steps, then A executes lines of code o/helpRelease^O starting with 
line [56] as depicted in Figure 

Sync2.CAS(_L, A) succeeds 

v 
5G 
O 

Figure 12: A's call to helpRelease^ () 

(c) If K and Q take enough steps, then B executes lines of code of helpReleaseg () and 
doPromotegO as depicted in Figures [73l and [771 respectively. 

Sync2.CAS(±,B) fails 
v 

56 57 58 59 60 61 62 
• >• >• >• >• >• > 



I doPromotegO 

Figure 13: i3's call to helpReleaseg () 

^{j,seq) = PawnSet. promote 



64 65 66 67 68 

->m — K?> true > • — 



70 
f alse 



Figure 14: B's call to doPromotegO 

(d) A < 7 = Jpl. 

(e) V te[A , 7); R(t) = {B}. 

(f) At time 7, Syncl = Sync2 = _L. 

(g) No promotion event occurs at lock L during [17, 7). 
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(h) The PawnSet.promoteQ operation at time 7 does not return a value in 
{(a,b)\ae{JC,Q},ben}. 

(i) If the PawnSet. promote () operation at time 7 returns a non-(_L, _L) value then B's cease-release 
event ttq occurs at time 7. 

(j) If the PawnSet.promoteQ operation at time 7 returns value (_L, _L) then B's cease-release event 
9j3 occurs at t' = J^Sl > ^ an d throughout [7, t'] no process is promoted, and V te r 7t n } R(t) = 
{B}. 

(k) Either IC or Q calls doCollect () , specifically during [I 2 ,7]- 



Proof. Proof of (jaj): We first show that for all t € [I^,^^], R(t) = {£, Q} and then show 
that A = From Claims lrl24Tj ej) IC calls helpRel ease^-() in line 1391 after time I 2 • From 

Claim |D. 24l f[aj). IC is a releaser of L at time I 2 . From an inspection of Figures [8] and throughout 



[I±, K, does not execute a call to helpReleaseg () or doPromote^ () . Also from an inspec- 

tion, IC fails to decrease Ctr from 1 to at vj^, thus JC's cease-release event 4>K. does not occur. 
Since /C's cease-release events t/c,ttic and 9^ only occur during helpReleaseg () or doPromoteg () 

- M 



(Claims ID.7f fe|) and lD.7l ffj)). it follows that /C is a releaser of L throughout [I 1 

From Claim EM©, Q calls helpRel easegO, respectively either in line [30j or line |43J after 
time I 2 ■ From Claim ID.24[ jaj) , Q is a releaser of L at time I 2 . From an inspection of Figures ITOl 
andlll| throughout [1%, $q^~] Q does not execute a call to helpReleaseg () or doPromoteg () . Also 
from an inspection, Q does not execute a Ctr. CAS (1,0) operation in line 1361 and thus Q's cease 
release event <f>Q does not occur. Since Q's cease-release events rg,7Tg and 9q only occur during 
helpReleaseg () or doPromoteg () (Claims EDjej) andlH7p)l). it follows that Q is a releaser of L 



throughout [I^i^f]. 

Then for all t G [/ 2 ~,§H {K, Q} C R(t) since Jf < I 2 and ^ = minC^, ^~). From 



Claim ID.24ric| , it follows that a process can become a releaser during I2 only if it is promoted by 



a releaser of L. Then to show that for all t g [I 2 , c~4~], R(t) = {IC, Q}, we need to show that no 



process is promoted by IC or Q during [J 2 ,e^~]. If a process was promoted by IC or Q during 



l I 2^^~] then b y definition cease-release events tt/c or ttq would have occurred during [J 2 , £34"], 
but as shown above this does not happen. 

From Claim ID .24[ jaj). Sync2 = _L at time I 2 . From a code inspection, Sync2 is changed to 
a non-_L value only in line [56] (during helpRelease () ), moreover only by a releaser of L (from 
Claim Since for all t € [/^,§H R(t) = {IC, Q} and §^ = min(^ ; it follows 



then that Sync2 = _L throughout [I 2 ,$^] and A executes a successful Sync2.CAS(_L, A) operation 

1—1 I r pi 

in line [56l Thus A 7 s cease-release event T4 occurs at e^p. 

Since Sync2 = 1 throughout [1^,/+] (Claims ESStjaj) andESiljgj)) and throughout [I 2 ,£^}, 

I r p| |rp| 

it follows that Sync2 was changed to a non-_L value for the first time at c^p*, thus A = Then it 
follows for all t € [Ig - , A), R(t) = {IC, Q}, and Sync2 = _L throughout [I 2 ,X) 

Proof of ()b]): From Part (jaj), A's cease-release event ta occurs at A = J?^, and thus ,/4's 
Sync2.CAS (_L, *4) operation in line 1561 succeeds. Then from the code structure A does not satisfy 
the if-condition on line 1561 and returns from its call to helpReleaseg () . Thus, Figure [121 follows. 

Proof of (jcj), ©, (jej), ©, (jgj), ©, (0) and ©: From Part (jaj), A = ^ and for all 
t € [I^A), = {IC,Q} and Sync2 = ± throughout [I^A) and cease-release event T4 occurs at 
A. Then A ceases to be a releaser of L at A, and thus R(X) = {B} and Sync2 = A 7^ _L at A. From 
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Claim lD.24f jcj) it follows that B will continue to be the only releaser of L until the point when B 
ceases to be a releaser of L or promotes another process. Let t > A be the point in time when B 
ceases to be a releaser of L. Since B ceases to be a releaser of L if it promotes another process (by 
definition of cease-release event 7tb), it follows that B is the only releaser of L throughout [A, t). 
Then from Claim ID. 151 it follows that B has exclusive write-access to Syncl,Sync2 and exclusive 
registration-access to PawnSet throughout [A, t). 

I F ryi I F /?i 

Now consider B's helpRelease^Q call. Since A = s^p < and Sync2 7^ _L at A and B has 
exclusive write-access to Sync2 throughout [A,i), B fails the Sync2.CAS(_L, B) operation at and 
thus satisfies the if-condition of line [56] It then executes lines 1571-1621 and calls doPromotegQ in 
line [62] Then Figures [13] and Q3] and Part (jej) follows immediately. 

We now show that 7 = Jf^ < t. Since A = ^ and ^ < Jpl < J|S it womc i follow that A < 7, 
and hence we would have proved Part (jdj. And since B is the only releaser of L throughout [A, t), 
we would have proved Part (jej) as well, i.e., B is the only releaser throughout [A, 7). 

During doPromoteg Q , B executes a PawnSet.promoteQ operation in line 1651 Since JC and 
Q are the first two releasers of L during T (Claim ID.24lfb"|) ). and only a releaser executes a 
PawnSet.promoteQ operation (Claim ID. 18j) . and A ceased to be a releaser at ^fPH it follows 

that £>'s PawnSet.promoteQ operation in line [65] is the first PawnSet. promote ( ) operation, and 



thus 7 = Since none of £>'s cease-release events occur during [^ffH ^g~], t ^ ^' ' 



During B resets Syncl and Sync2 in lines 1581 and 1601 respectively, and since B has 

I F f I 1/? F 1 1/? F I 

exclusive write-access to Syncl and Sync2 throughout [sjjpl, at time 7 = Syncl = Sync2 = 
_L. Thus, Part © follows. 

By definition 7 is the point in time when the first PawnSet.promoteQ operation occurs. Since 
a promotion event occurs only when a PawnSet.promoteQ operation returns a non-(_L,_L) value, 
it follows that no promotion event occurs during [i^~,7). Hence, Part (jgj) follows. 

Since B has exclusive write-access to Sync2 throughout [A, and Sync2 = A at A 
reads the value A from Sync2 in line 1591 and executes a PawnSet. remove (A) operation in line 1611 
Since B executes PawnSet. remove (A) and PawnSet. remove (B) in lines [61] and [64] during [A, 7) and 
B has exclusive registration-access to PawnSet during [A, 7), it follows from the semantics of the 
AbortableProArray n object that B's PawnSet.promoteQ operation at time 7 does not return values 
in {{a,b)\a G {A, B} = {K, Q} , b € N}. Hence, Part © follows. 

Case a - B's PawnSet.promoteQ operation returns a non-(_L, _L) value: Then £?'s cease-release 
event 7rg occurs at i§^= 7 (Claim [D.18p . and thus Part ® holds. 

Case b - B's PawnSet.promoteQ operation in line [65] returns (_L,_L). Then B did not find 
any process to promote, and thus cease-release event njg did not occur. From the code structure 
B goes on to execute a Ctr.CAS(2,0) operation in line [68] Since Ctr = 2 throughout I2, it follows 



that £>'s Ctr. CAS (2,0) operation succeeds, and thus B's cease-release event 9q occurs at ip and 

try oi i/? F I 

the intervals I2 and T end. Therefore t' = > = 7. Clearly, B does not promote any process 
in = [7/], and thus Part fj]) holds. 

Proof of ([k]): From an inspection of Figure [9] /C executes a Syncl. CAS(_L, /C) operation in 

line [37] Since I2<^<W^<^<1 ( from Parts O and (|d])), it follows that G [I 2 _ ,7]. 
From an inspection of Figures [TOl and [TUl Q may or may not execute a Syncl. CAS (_L, 00) operation 
in line [26] If Q executes a Syncl. CAS (_L, 00) operation in line [26] since 1^ < < < 7, it 

follows that ipG [ZT,7]. 

Since for all t G [1^,7], i?(t) C {/C, Q} (from Parts jaj) and (jej)), and only releasers of L 
have write-access to Syncl (Claim [D.15|) . and Syncl = _L at (Claim ID.24f [aj)). it follows that 
either K. or Q executes a successful CASQ operation on Syncl. Then from the code structure it 
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follows that either K, or Q executed a call to doCollect () in lines 1381 or 1291 respectively. Since 
|P < jEp- = < 7 and < < 7, K, or Q executed a call to doCollect () during 

[J 2 -, 7 ]. ' ~ □ 

Claim D.26. If a process p is promoted at time t' € T and a PawnSet. reset () has not been 
executed during [lQ,f], then p did not execute a PawnSet. abort (p, s) operation during [Iq ,t'], 
where s G N. 

Proof. Suppose not, i.e., p executed a PawnSet. abort (p, s) operation at time t < t' . Since p has 
not been promoted before t' > t it follows that a PawnSet.promoteO operation that returns (p, •) 
has not been executed before t. Then from Claim lET5l jaj) and the semantics of PawnSet, it follows 
that the p-th entry of PawnSet is not at value (PRO,s) = (2, s) throughout [ijT,t]. Then p's 
PawnSet. abort (p, s) operation at t succeeds, and thus p writes value (ABORT, s) = (3, s) to the 
p-entry of PawnSet. Then for p to be promoted at t' > t, it follows from the semantics of PawnSet 
and Claim [D75t fa]) . that during [t, t') a PawnSet. reset () operation and then a PawnSet. collect (^4) 
operation where A\p] = s, must be executed, followed by a PawnSet.promoteO at t' that returns 
(p, s). This is a contradiction to the assumption that a PawnSet. reset () is not executed during 
[I ,t'\. □ 

Let £ be the number of times a promotion occurs during T. For all i G {1, . . . ,£}, define to 
be the i-th interval [Q^ , Qf] that begins when the i-th promotion occurs during T and ends when 
the promoted process ceases to be a releaser of L. Let Vi be the process promoted at f2^. 

Claim D.27. 7/ I2 7^ and R(Iq) = and at time Iq , Syncl = Sync2 = _L and PawnSet is 

candidate- empty, then the following claims hold for all i G {1, . . . ,£}: 

(a) If £ > 1, then 7 = and ii(il^) = {V\}, and Syncl = Sync2 = _L at Or, and no 
PawnSet. reset () operation has been executed during 

(b) If R{VLT) = {Vi}, then for all t G [Ur,Qf) } R(t) = {Vi}. (i.e., Vi is the only releaser 
throughout Vti) 

(c) If i 7^ I and R(Q^) = {Vi}, then flf = and R(Q^ +1 ) = {Vi+\}. (i.e., V%+i is the only 
releaser at 

(d) Ifi + t, then 0+ = nr +1 and R(nr +l ) = {V l+1 }. 

(e) For all t G R(t) = {Vi}. (i.e., Vi is the only releaser throughout Ojj 

Proof. Proof of (jaj): If the PawnSet.promoteO operation at time 7 returns value (_L,_L), then 
from Claims [D.25fe j) and lD.25l i|) it follows that no promotion occurs during T, which is a contra- 



diction to £ > 1. Thus, the PawnSet.promoteO operation at time 7 returns a non-(_L,_L) value. 
By definition 7 is the point when the first PawnSet.promoteO operation occurs, and f2^~ is the 
point when the first promotion occurs and V\ is the process promoted at . Then 7 = and 
V\ is the first promoted process. From Claim ID.25l fe"j). B is the only releaser of L at the point in 
time immediately before time 7. Then from Claim [D.25t fH) ^ follows that B promotes V\ at time 
7 = and B ceases to be a releaser of L at 7, therefore R(~~f) = {V\}. From Claim [D.25l ffj) it 
follows that Syncl = Sync2 = J_ at 

From an inspection of the code, a PawnSet. reset () is executed only in line 1671 an d it can be 
executed only after a PawnSet.promoteO is executed in line[65j Since 7 is the first point when a 
PawnSet.promoteO is executed, it follows that no PawnSet. reset () operation was executed during 

[io~ 7]- 
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Proof of ([b]): Since -R(r^ ) = {Vi}, and is the point when V% ceases to be a releaser of 
L, for all t G [0,7, Qf), {Vi} C R(t). To show that for all t G [ft; - , fit), fl(t) = {Vi}, we need 
to show that no other process becomes a releaser of L, during [fir, fit). Suppose some process 
q ^ Vi becomes a releaser of L some time during that interval. Since fir > fir = 7 > 1^7 , from 
Claim [D.24l f[ci) it follows that Vi promotes q during [Q~,£lf). Then from Claim [D. 181 TVs cease- 
release event 717^ occurs during [fir, fij 1- ), and thus Vi ceases to be a releaser of L during [fir, fit). 
Hence a contradiction. 

Proof of ([cj): Since i < £, it follows that there exists a process Pj+i that becomes a releaser 
of L during T. By definition, 7^ and V%-\-\ are the i-th and {% + l)-th promoted processes during T, 



respectively. Since fiL_j > > ^~ = 7 > -^T' from Claim IIX24T[cl) it follows that no other process 
becomes a releaser after V% became a releaser and before Vi+i becomes a releaser, i.e., during 
[fir,fi~ ]. Moreover, since R(U7) = {Vi}, it follows that the next process to be promoted, i.e., 
Vi+i, is promoted by the only releaser of L, Vi- Then from Claim ID. 181 it follows that Vi promotes 
Vi+i by executing a PawnSet.promoteO in line[65]that returns (Vi+i,s), where s G N, and event 
7PP; occurs at Jp3 Then Vi ceases to be a releaser of L at and thus fit = $p^. Since is the 
point when V%+\ becomes a releaser of L, it follows that Qf = Q7 +1 , and thus = {Vi+i}. 

Proof of ((dj): We prove by induction that for all k < I, R(Q7 +1 ) = {Vk+i} and fi^ = Q7 +1 . 

Basis (k = 1) From Part (jaj), Vi is the only releaser of L at fir, and clearly £ > k = 1. Then 
from Part (jcj), fi^ = fir and ii(O^) = {V 2 }- 

Induction step (k > 1) By definition Vk is the promoted process at fir, and since |-R(f2^-i)l = 
1 and fifc"-i = ^fc (°y the induction hypothesis), it follows that Vk is the only releaser of L at fir. 
Then from Part (jcj), fi+ = fir +1 and R(SIZ +1 ) = {V k+i }. 

Proof of (jej): From Part jaj), i?(fir) = {Pi}, and thus from Part ©, for all t G [fir,fi+), 
= {Pi}. From Part ©, for all i > 1, R^17) = {Vi}, and thus from Part ©, for all 
t G [S~2~ , ) , -R(t) = {Pi}- Hence, our claim follows. □ 

Claim D.28. If I2 7^ and R(Iq) = and at time I7~ , Syncl = Sync2 = _L and PawnSet is 

candidate- empty, then the following claims hold for all i G {1, . . . , £}: 

(a) A PawnSet. reset () operation is not executed during [I7~,Q7]. 

(b) Vi executes lines of code o/lock^ () starting with line\^ as depicted in Figure [751 



(c) Vi's call to lock-p^O returns 00, and Vi finishes lockp. () during T, and Role["Pj] = PAWINLP 
when Vi 's call to lockpv () returns. 

(d) Exactly one cease-release event among 7pp. and 9-p i occurs during Vi 's call to doPromote-p^ () . 

(e) Vi executes lines of code of release-p. () starting with line^34\as depicted in Figure [TR 

(f) Vi does not write to Syncl or Sync2 during [fir, fit]. 

(g) J| < fir < fip < fit < ifl and fit < 1+ . 

(h) If i 7^ £, then a PawnSet. reset () operation is not executed during [Jr,fit]. 

(i) Throughout [7, fi^] ; Syncl = Sync2 = _L. 

W if£>i,4 = nj = ^. 

(k) For all t G [7,/ 2 + ), \R(t)\ = 1. 
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Figure 15: Vi's call to lock^ () 
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doPromotep. 



Figure 16: TVs call to release^ () 



(I) -R(I^) = and at I^, Syncl = Sync2 = J_ and PawnSet is candidate- empty. 

Proof. Proof of (jaj)-([h]): We prove Parts (jaj)-(jh]) by induction on i. First, we prove Part (jaj) 
for i = 1. Second, we show that if Part (jaj) is true for a fixed i, then Parts (Jb])-(jh|) are true for i. 
Finally, we show that if Parts (jaj)-(Jh|) are true for i, then Part (jaj) is true for i + l, thus completing 
the proof. 

From Claim ID. 27lfefl) . no PawnSet. reset () operation has been executed during [7(7, f27"]. Hence, 
Part (jaj) for i = 1 holds. 

Now we show that if Part (jaj) is true for a fixed i, then Parts (JbJ)- (JEJ) follow for i. 

Proof of Parts (jbj) and (jcj) if Part (jaj) for i is true: Let q be the process that promotes 
Vi at fi~ . Then g's PawnSet. promote () operation in line [65] returned value {V~i,s), where s £ N, 
and = Jjp] Then from the semantics of the PawnSet object it follows that the Vi-th entry of 
PawnSet was (REG, s) = (1, s) immediately before fiTC Then from Claim ITXBl jbj) it follows that some 
process (say r) executed a PawnSet. collect (A) operation in line 1551 where A[Vi] = s. Then from 
the code structure, r read applyfT^] = (REG,s) in line [52l By Claim [D~6t jaj) applyf'Pj] is set to value 
(REG, s) only by process Vi when it executes a successful apply[7 7 i].CAS((_L, _L), (REG, s}) , therefore 
Vi executed the same and broke out of the spin loop of line [2j Note that 

Since Ctr = throughout Iq, Ctr = 1 throughout I\ and Ctr = 2 throughout I2, it follows that 
Ctr is increased only at points IT" and IrT during T. Since AC and Q are the first two releasers of 
L and they increased Ctr to 1 and 2, respectively, at Jj~ and respectively, it follows that no 
other process apart from AC and Q increases the value of Ctr during T. Since > il^ = 7 > 
(by Claims ID.25t jaj) and ID.25ljd"|) and ID,27t jaj) ) , Vi becomes a releaser of L only after 1^ (the point 
at which Q became a releaser of L). Thus, Vi is not among the first two releasers of L, thus 
Vi £ {AC, Q}. Then it follows that Vi does not increase Ctr. Therefore Vi's Ctr.incQ operation in 
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line [5] returns value 2 = PAWN, and thus Vi sets Ro\&[Vi] to 2 = PAWN in line [5) Then from the 
code structure Vi satisfies the if-condition of line [6] and proceeds to spin in line [71 

Case a - Vi receives a signal to abort while busy-waiting in line Then Vi stops 
spinning in line [7] and executes abort-p. (). Since Vi last set Rolef'Pj] to PAWN in line El it then 
follows from the code structure that Vi proceeds to execute lines PT81I201 and satisfies the if-condition 
of line 1201 and then executes a PawnSet. abort (Vi, s) operation in line 1211 

Since a PawnSet. reset () operation has not been executed during [Iq,£1~], from Claim ID, 26 1 
it follows that Vi did not execute a PawnSet. abort (Vi, s) operation in line EH during 
thus ipD > ft-. Since Vi has exclusive-registration access to PawnSet during [Q i , and p has 
not executed any of its cease-release events or reset PawnSet during [ip.,^5rj, and lp. < f2~, it 
then follows that PawnSet was not reset during [f27~, Ipj^. Then since the Vi-th entry of PawnSet 

was last changed to (PRO,s) = (2,s) at it remains (PRO,s) throughout [J2^,J^|. Then Vi's 
PawnSet. abort (Vi, s) operation in line 1211 returns false by the semantics of the PawnSet object. 
Then p satisfies the if-condition of line 1211 proceeds to set Role["Pj] to PAWN_P in line 1221 and then 
returns oo from its call to abort^ () and lock^ (). 

Case b - Vi does not receive a signal to abort while busy- waiting in line 
Recall that process q promotes Vi at J7^~ by executing a PawnSet.promoteO operation in line [651 
that returns value (Vi, s), where s € N. Since processes in the system continue to take steps, process 
q sets its local variable j to value Vi in line EH and proceeds to fail the if-condition of line [66j and 
then executes line 1701 where (j,seq) = (Vi,s). Then q executes a apply [Vi]. CAS ((REG, s), (PRO,s)) 
operation in line 1701 

Recall that process r read value applyfT-^] = (REG, s) in line 1521 and lp. <f2<^r = f51. From 
an inspection of the code, apply[7-j] can change from value (REG, s) only to value (PRO, s) and from 
value (PRO, s) only to value (_L, J_). Also, apply["Pj] can be changed from (PRO, s) to (_L, _L), only if 
p executes line [32] or [Ml Since p is spinning in line[7Jit follows that a apply["Pi].CAS ((PRO, s), (_L, lY) 
operation is not executed during (£1^,$®), and thus apply [Vi] = (REG,s) throughout (fi^JZQl). 
Therefore, q executes a successful apply[7 , j].CAS((REG, s), (PRO, s)) operation in line [70] and thus 
apply[7Vj = (PRO,s) at JJE. 

Since Vi is busy-waiting in line [7J for applyf'Pj] to change to (PRO,s), it then follows that Vi 
busy-waits throughout (0,^,$®), and reads applyf'Pj] = (PRO,s) when it executes line [7J for the 

first time after Jj^h Then Vi breaks out of the spin loop, and then from the code structure, Vi 
proceeds to set RolefPi] to PAWN_P in line[9l breaks out of the role-loop in line 1121 executes line [TBI 
and fails the if-condition of line 1131 an d executes lines I161[T7] and returns from lockp^ () in linefTTI 
with value oo. Note that £1^ < lpj . 

Proof of Parts ([d]), (jej) and @ if Part (jaj) for i is true: Since Vi is the only releaser of L 
throughout ,flf) (Claim lD.27f [e"j)). it follows from Claim [D. 151 that V% has exclusive write-access 
to objects Syncl and Sync2 and exclusive registration-access to PawnSet throughout [f^~ ,Qf)- 

Since Vi returns from its call to lock^O with value oo (by Part (jcj)), Vi executes a call to 
release^ () (follows from conditions [b] and [d]) . 

Since Ro\e[Vi] = PAWN.P when Vi's call to lock^ () returns (by Part (jcj)), Ro\e[Vi] = PAWN.P 
at ^i=p~. Since Rolef'Pj] is unchanged during [J^, Jp^~] (follows from Claim [DT4l fb|) ) . it follows from 
the code structure that during TVs call to release-p^ (j) , Vi only executes lines IM11351 H2l and H5H501 
Then Figure [161 follows. 

From an inspection of Figures PT5l and [161 Vi does not execute a call to helpRelease-p. () or exe- 
cute a Ctr.CAS(l,0) operation in line [36] during release^ (). Then from Claims ID .7f [aj) and lD.7l jb"l) 

V^s cease-release events <jyp- and T-p i do not occur. Since Vi executes a call to doPromote^ () only 
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in line 1461 it follows from Claim ID. 191 that exactly one cease- release event among it-p. and 9-p i occurs 
during Vi's call to doPromotep^ () . Hence, Part ([d|) follows. Then £lf is the point when cease- 
release event ir^ or 6-p { occurs. From an inspection of Figures [15] and [16] and the code, it is clear 
that Vi does not change Syncl or Sync2 during lockp 4 () and release^ (.) Therefore, V% does not 
change Syncl or Sync2 during [fir ; OT]. 

Proof of Part (jgj) if Part (jaj) for i is true: As argued in Part (jbj) and (jcj), Jp < and 
nr < i|. or nr < J2D Since §!. < JJP and < JJP, it then follows that < Q~ < JJP. 

From Part ((d|), exactly one cease-release event among 7rp i and 0pv occurs during Vi's call to 
doPromote-p^ () . If cease-release event 9p i occurs then Qf is the point when V^s cease-release 
event 6-p i occurs, i.e, SlJ = i^r 1 . Then Vi changes Ctr to and the Ctr-cycle interval T ends at 

If cease-release event 7Tp i occurs then Qf is the point when TVs cease-release event 7Tp. occurs, i.e, 



Since Vi calls doPromotep i () only in line 06] (by inspection of Figure [To]) , it then follows that 

n t g {W> W\ < V- Thus ' Part @ holds - 

Proof of Part ([h]) if Part (jaj) for i is true: As argued in Part (jf|), exactly one cease-release 
event among n-p. and 6-p. occurs during V^s call to doPromote-p. () . If cease-release event 9-p i occurs 
then flf is the point when V^s cease-release event 6-p i occurs, i.e, fi+ = ^P. Then Pj changes Ctr 



to and the Ctr-cycle interval T ends at ftf = c^P, and thus I = i. This is a contradiction to 
the assumption i ^ £, hence ViS cease-release event 7Tp 4 occurs during TVs call to doPromotep i (). 
Then £lf is the point when 7Vs cease-release event 7rp 4 occurs, i.e, £lf = Mj^. From an inspection of 
Figures [T5l and [161 and the code, it follows that Vi does not execute a PawnSet. reset () operation 
during [J^ , and 7^ calls doPromote-p^ () only in line[46] Since Qf = J^P, from an inspection of 



the code of doPromotep- (), Vi does not execute a PawnSet. reset () operation during [ip-Kip - ' ]. 
Then Vi does not execute a PawnSet. reset () operation during 

Since V% is the only releaser of L throughout [fl^fif) (Claim ID.27flel) ). it follows from 
Claim ID.15I that Vi has exclusive registration-access to PawnSet throughout [0^,0+). Then 
since no PawnSet. reset () operation was executed during and V% does not execute a 

PawnSet. reset () operation during it follows that no PawnSet. reset () operation is exe- 

cuted during [lQ,Qf]. Hence, Part (|h|) holds. 

Finally, we show that if Parts (jaj)- (EJ) are true for i, then Part (Jaj) is true for thus completing 
the proof. From Part (jh|) for i, no PawnSet. reset () operation has been executed during [/J - ,!^]. 
From Claim E2DJd|), Qf = Qr +1 . Then Part (jaj) f or i + 1 holds. 

Proof of ©: From Claim EUlJaj) , Syncl = Sync2 = _L at = 7. From Claims EIDjaj) 
and [Tl27p]) . it follows that 7 = Oj" < nf = Q, 2 < ^ = 9,^ . . . < 0/_ x = QJ < O/. 

From Claim EUlJej), for all t € R(t) G {Vi}. Then Vi has exclusive write -access to 

Syncl and Sync2 throughout Since V% does not change Syncl or Sync2 during [Q~,f2+] 

(Part (jfj)), it then follows that Syncl = Sync2 = _L throughout [JlT/,^] = [7,^]. 

Proof of ([]]): As argued in Part (jj), exactly one cease-release event among 7Tp £ and 9p e occurs 
during Vis call to doPromotep £ () . If cease-release event irp t occurs then Vi promotes some process, 
and thus the number of processes that get promoted during T is larger than £, which contradicts 
the definition of I. Hence, cease-release event 9-p t occurs during doPromotep,, () and f^J" is the 
point when cease-release event 8-p e occurs, i.e, = $p^. Since Ctr is changed from 2 to when 9-p l 

occurs, the Ctr-cycle interval T ends at £1^ = IjjP, and thus 1% = = J|P. 
Proof of (Jk]) and 
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Case a - I = : Consider the first PawnSet. promote () operation at 7. Since I = 0, the 



PawnSet.promoteO operation at 7 returns value (_L,_L). Then from Claim lD.25t| ]]). it follows that 
B's cease-release event % occurs at t' = > 7, and throughout [7, t'] no process is promoted, 
and for all t G [7,t')j R(t) = {£>}. Since Ctr is changed from 2 to when 9b occurs, the Ctr-cycle 
interval T ends at t! = J§& and thus if = ip= t' . Then for all t G [7,*') = [7, J^), |-R(i)| = 1. 

From an inspection of Figure ITU and the code, it follows that B executed a PawnSet. reset () 
operation in line [67] during [7, t'], and thus PawnSet is candidate-empty immediately after. Since for 
all t G [7, t'), R(t) = {£>}, B has exclusive registration-access to PawnSet throughout [7, i') (follows 
from Claim ID. 15|) . Then it follows that PawnSet is candidate-empty at t' = lf. 

Since for all t G [7, t')j R(t) = {£>}, B has exclusive write-access to Syncl and Sync2 throughout 
[7, t') (follows from Claim lD,15p , Since Syncl = Sync2 = _L at 7 (Claim ID.25lffj) ). and B does not 
write to Syncl and Sync2 during [7, i'], it follows that Syncl = Sync2 = _L throughout [7, t'\ = 

[7,4]- _ 

Case b - t > 1 : From Part ^, if = Of = l^f. Then from Part (0), it follows that Syncl = 

Sync2 = _L throughout [7, if], and from Claim |P~27l f[ei). it follows that for all t G [fi^, Clt] = [7, if), 
\R(t)\ = 1. Since Vi ceases to be a releaser of L at Uf, R(lf) = 0- 



Since Qf = Vi executed line [68] and before that line [67J Hence, Vt executed 



a 



PawnSet.resetO operation at ^ < Qf. Since > and > Q e (by Part Q), it 



follows that sp~> • Hence, Vi executed a PawnSet.resetO operation at G , Slf]- Since 
7^ is the only releaser of L throughout ,£lf) (Claim [D.27l f[e|>). it follows from Claim ID. 151 that 
Vi has exclusive registration-access to PawnSet throughout \£T^ £lf). Then it follows that PawnSet 
is candidate-empty at O^T = if ■ D 

Claim D.29. R(Iq) = and at Iq , Syncl = Sync2 = 7 and PawnSet is candidate- empty for any 
Ctr-cycle interval T during history H . 

Proof. Let T k denote the fc-th Ctr-cycle interval T during history H. We give a proof by induction 
over the integer k. Basis - At 77" for T 1 , the claim holds trivially since all variables are at their 
initial values (Syncl = Sync2 = 7 and PawnSet is candidate-empty). 

Induction Step - By the induction hypothesis, at 1^ for T k ~ 1 , R(Iq) = 0, and Syncl = 
Sync2 = 7 and PawnSet is candidate-empty. Since T k begins immediately after T k ~ 1 ends, to prove 
our claim we need to show that, when T k_1 ends, there are no releasers of L and Syncl = Sync2 = 7 
and PawnSet is candidate-empty. The time interval T k ~ l ends either at time if or time if. 

Case a - T k ~ l ends at time if: Then I 2 = 0. From Claim EM]® it follows that K 
is the only releaser of L during I\. Since I2 = 0, it then follows from Claim lD.23ltej ). that A7s 
Ctr. CAS (1,0) operation in line [36] is successful, and the interval I\ as well as T fc_1 ends at time 



ipp. Then /C's cease-release event (ft/c occurs at = if, and thus there are no releasers of L 
immediately after T^'" 1 ends. And from Claim lD.23t jgj). it follows that Syncl = Sync2 = 7 and 
PawnSet is candidate-empty when T fc_1 ends. 

Case b - T k ~ 1 ends at time if: Then I2 7^ 0. Then our proof obligation follows immediately 
from Claim EM©. " □ 

Note that in the following claims, notations Iq, 1%, I2, A, 7, f2j, fC, Q and Vi are defined relative 
to a Ctr-cycle interval, as was defined previously in pages l38l 1431 and 1471 The exact Ctr-cycle interval 
is clear from the context of the discussion. 

Lemma D.30. The mutual exclusion property holds during history H . 
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Proof. For the purpose of a contradiction assume that at time t, two processes (say p and q) are 
poised to execute a call to LreleaseO. From Claim [D.13lTb|) . it follows that both p and q are 
releasers of L at t. Consider the Ctr-cycle interval T such that t £ T. 

From Claim ID. 291 it follows that at IZ, Syncl = Sync2 = _L and PawnSet is candidate-empty, 
and R(I ) = 0. Then from Claims IL\23te l) . HX23llf] ) . IL\25tei ) . lL\25Tle1 and IL\25l|kj) . it follows that 
during T, lock L has two releasers only during [J^~, A). Then t € A). Also from Claim ID. 25 flaj ). 
for all t G [I2 , A), R(t) = {/C, Q}. Then {p, q} = {fC, Q}. Let p = K, and q = Q without loss of 
generality. 

Recall that 1^ is the point in time when Q increases Ctr from 1 to 2 and sets Role[Q] to QUEEN 
in lineEl Since g's call to lockQ returned a non-_L value, it follows from an inspection of Figure 1101 
that Q returned either in lineHTJor line[271 Then Q either read a non-_L value from Syncl in line [HI 
or Q failed the Syncl. CAS (_L, 00) operation in line [26l Since Syncl = _L at 1% (by Claim [D.24l ffaj)). 
and I2 = ig, it then follows that Syncl is changed to a non-_L value during [/^"ji]. Clearly, Q does 
not change Syncl during 

Recall that 1^ is the point in time when K, increases Ctr from to 1 and sets Role[/C] to KING 
in line [5l It follows from an inspection of Figure El that /C does not change Syncl during lock^O, 
and thus during [ii",t]. Since Syncl is changed to a non-_L only by a releaser of L (by Claim |D.15|) 
and Syncl = _L at and the only releasers of L during [J^~, t] do not change Syncl, it then follows 
that Syncl = _L throughout [i^t]- Hence, a contradiction. □ 

Claim D.31. Consider an arbitrary Ctr-cycle interval T. 

(a) If p is collected during T and p does not abort, then p is promoted and notified during T. 

(b) 7/apply[p] = (REG, s) at Iq , where s 6 N, and p does not abort and p does not increase Ctr, 
then p is notified during T. 

Proof. Proof of (jaj): From Claim lD.291 it follows that at Iq , Syncl = Sync2 = _L and PawnSet 
is candidate-empty, and R(Iq) = 0- Then from Claim lD.25lfk"l) . it follows that exactly one call 
to doCollectQ is executed during T by a process q € {/C, Q}. Since processes are collected only 
during a call to doCollectQ, q £ {/C, Q} collects p during doCollect g () during T. And q does 
so by executing a PawnSet. collect (^4) operation in line I55| where A\p] = s £ N, and sets the p-th 
entry of PawnSet to (REG,s). Since a PawnSet. promote () that returns (_L, J_) is executed at 



during T, it then follows from the semantics of the PawnSet object that p was promoted during T. 
Then p = Vi, for some i < L Note that T does not end during [ft^ , flf ). 

We now show that p is also notified of its promotion during T. The process (say r) that 
promoted p by executing a PawnSet.promoteQ operation in line 1651 a l so goes on to notify p of its 
promotion by executing a apply[p].CAS ((REG, s),(PRO, s)) operation in line [TOJ Since p does not 
abort, it follows from an inspection of Figure fl5l and the code, that p spins on apply[p] in line [7] 
until its notification. Then p executes line [9] at f > ?P > |p = or. Since § < n+ and T does 
not end before Qf, it follows that p is notified during T. 

Proof of (jbj): Since p does not increase Ctr it follows that p reads Ctr = 2 every time it 
executes a Ctr.incO operation in line[5l and sets Role[p] = PAWN in line[5j Then p satisfies the 
if-condition of line [6] and spins on variables apply [p] and Ctr in line [3 Since Ctr is only changed to 
at the end of T, it follows that Ctr = 2 throughout [Jp, I^)- Then p busy-waits in the spin loop of 
line [7] until the end of T, or if it reads value (PRO, s), for some s £ N, from apply[p] in line [7J during 
T. Now, apply[p] is changed to value (PRO,s) by some process other than p, only if that process 
notifies p, i.e., executes a successful apply[p].CAS ((REG, s) ; (PRO, s}) operation in line [701 We now 
show that p is notified during T. 




53 



From Claim lD.291 it follows that at IZ, Syncl = Sync2 = _L and PawnSet is candidate-empty, 
and R(Iq) = 0- Then from Claim ID. 25 tiki) , it follows that exactly one call to doCollect () is 
executed during T by a process q € {JC, Q}. Consider the point when q reads applyfp] in line _ 
If q reads a value different from (REG,s), then some process must have notified p during [sp, cp^ 
and since Iq < Jp and i^l g T, our claim holds. If q reads the value (REG, s) from apply[p], then 
q collects p during T by executing a PawnSet. collect (^4) operation, where A[p] = s, in line [55] 
during T. Thus, our claim follows from Part (jaj). □ 

Claim D.32. If p registered itself in linel^ and incurred 0(1) RMRs in the process, and p does 
not abort, and all processes in the system continue to take steps, then 

(a) p finishes its call to lock p Q and returns a non-1, value. 

(b) p incurs 0(1) RMRs in expectation during its call to lock p Q. 

Proof. Proof of (jaj) and ((bj): From an inspection of the code of lock p Q, p incurs a constant 
number of RMRs while executing all other lines of lock p Q except while busy- waiting in lines [21 [7J 
and[H 

Consider p's call to lock p Q. By assumption of the claim, p registered itself in line [2] by 
executing a successful apply[p].CAS ((_L, _L) ; (REG, s)) operation in line[2j and incurred 0(1) RMRs 
in the process. Then p proceeds to execute a Ctr.incQ operation in line[5l and stores the returned 
value in Role[p]. A Ctr.incQ operation returns values in {KING, QUEEN, PAWN, _L}. If it returns 
_L, p repeats the role-loop, and executes another Ctr.incQ operation in line[5j From Claim lAT2l it 
follows that p repeats the role-loop only a constant number of times before its Ctr.incQ operation 
returns a non-_L value. 

Case a - p executes a Ctr.incQ operation in line [5] that returns KING. Then p sets Role[p] = 
KING in line [5] Then from the code structure p does not busy- wait on any variables, and proceeds 
to return oo in line 1171 and thus incurs only 0(1) RMRs. Hence, (jaj) and © hold. 

Case b - p executes a Ctr.incQ operation in line[5]that returns QUEEN. Then p increments 
Ctr from 1 to 2 in line [5] and sets Role[p] = QUEEN in line [5] Then from the code structure p 
proceeds to busy-wait on Syncl in line [Til Since p increased Ctr from 1 to 2, fl^l = J~ fo r S ome 
Ctr-cycle interval T. From Claim ID. 291 it follows that at Iq , Syncl = Sync2 = _L and PawnSet is 
candidate-empty, and R(Iq) = 0- Then from Claim ID.24l |gj) it follows that p does not starve in 
line [UJ Since p does not abort, it follows from an inspection of Figure [10] and the code, that p 
returns a non-_L value in hnell7j and p does not change Syncl. Hence, we have shown that Part (jaj) 
holds. Apart from p, the only releasers of L during T are {/C, Vi, ... , Vg}, where £ is the number of 
promotions during T. From an inspection of Figures [8] [9] [T5| [TBI and the code, it follows that only 
K, possibly writes a non-_L value to Syncl during T in line [371 Since Syncl is written to only be 
a releaser of L, and 6 T, it then follows that Syncl is changed to a non-_L value at most once 
during T. Then p incurs at most one RMR while busy- waiting on Syncl. Hence, we have shown 
that Part © holds. 

Case c - p executes a Ctr.incQ operation in line [5] that returns PAWN. Then p found Ctr 
to be 2 in line [5] and set Role[p] = PAWN in line [5] Then from the code structure p proceeds to 
busy-wait on applyfp] and Ctr in line[7J 

We now show that p does not starve while busy- waiting in line[7J Since Ctr = 2 at ffl it follows 
that feTfor some Ctr-cycle interval T. 

Subcase (i) - applyfp] = (REG,s) at Iq during T, for some s £ N. Then from Claim ID,31l fb"l). 
p is notified during T. Since p is notified during T and p does not abort, it follows that p does 
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not change apply[p], and thus applyfp] is changed from (REG,s) to (PRO,s) when p is notified. 
Since apply[p] is changed from (PRO, s) to some other value only by p, it then follows that applyfp] 
remains (PRO,s) when p reads apply[p] for the first time after p was notified. Then p incurs one 
RMR when it reads applyfp] in line [7] after its notification, breaks out of the spin loop of line 
proceeds to satisfy the if-condition of line [HJ and sets Role[p] = PAWINLP in lineO and proceeds to 
return oo in line [T71 Then we have shown Parts (jaj) and ([b]) hold. 

Subcase (ii) - applyfp] ^ (REG,s) at Iq during T, for some s £ N. Consider the 
only call to doCollect () during T by q G {fC,Q}. If p registered itself (i.e., executed 
its apply[p].CAS((_L, _L),(REG, s)) operation in line [2]) before q reads applyfp] in line [52] during 
doCollect g ()), then q collects p during T. Then from Claim lD.31l f[aj). p is collected and pro- 
moted during T, and eventually notified. Then Parts (jaj) and (jb|) hold as argued in Subcase 
(i)- 

If p registers itself after q attempts to acknowledge p during T, then no process changes apply[p] 
during T. Then p continues to busy-wait in line until the Ctr-cycle interval T ends and Ctr is 
reset to 0. 

If Ctr is increased to 2 before p reads Ctr again in line [7J then let T" be the Ctr-cycle interval 
that starts when Ctr was reset to at the end of T. Since apply[p] was changed to a non-(REG, s) 
value before the start of T", it follows that apply[j>] = (REG, a) at the start of T'. Then from 
Claim lD.3Hffb|) . p is acknowledged, collected, promoted during T', and eventually notified. Then 
Parts (jaj) and (jbj) hold as argued in Subcase (i). 

If Ctr 7^ 2 when p reads Ctr again in line [7J then p incurs one RMR in line [7J breaks out of 
the spin loop, and proceeds to execute line [HJ If p satisfies the if-condition of line [HJ then p has 
been acknowledged during some Ctr-cycle interval T". Then from Claim lD.31f [aj). p is collected, 
promoted during T", and eventually notified. Then Parts (jaj) and (jbj) hold as argued in Subcase 
(i). If p fails the if-condition of line[HJ then p proceeds to repeat the role-loop. Consider p's second 
iteration of the role-loop. If p sets Role[p] = {KING, QUEEN} in lineEl then Parts (jaj) and JH) hold 
as argued in Case a and Case b. If p sets Role[p] = PAWN in line[5j then it follows that jjf G T'", 
for some Ctr-cycle interval T'", such that apply[p] = (REG,s) at Iq for T'". Parts (jaj) and (jbj) hold 
as argued in Case c(i). □ 

Lemma D.33. If all processes in the system continue to take steps and p does not abort, then 

(a) p finishes its call to lock p () and returns a non-1- value. 

(b) p incurs 0(1) RMRs in expectation during its call to lock p (). 

Proof. From an inspection of lock p (), p incurs a constant number of RMRs while executing all 
other lines of lock p () except while busy- waiting in lines El [71 and [HI 

Consider p's call to lock p (). Process p first attempts to register itself in line [21 by attempting 
to execute an apply [p]. CAS ((_L, _L) ; (REG, s)) operation. Now, applyjp] is changed from (_L, _L) to a 
non-(_L, _L) value only by p (Claim iDlHj aj)), If apply[p] = (_L, _L) at , then p executes a successful 
apply[p].CAS((_L, _L), (REG, s)) operation in line[2]and incurs only one RMR. Then our claims follow 
immediately from Claims lD.32l faj) and lD.32 l[b"l). 

If apply[j>] ^ (-L,-L) at iff- , it follows that some process p' executed a successful ap- 

ply[p]. CAS ((_!_, _L), (REG, s')) in line [21 during lock p (), and applyfp] ^ (JL,JL) throughout [Jp,if"]. 
Since calls to lock^O are not executed concurrently, it follows that p' has completed its call to 
lockpO during [Jf,fH 

Case 1 - p"s call to lock p () returned _L. Then it follows from the code structure that 
p' executed a call to abort p () and returned from line [I8j or [33l Since p executed a successful 
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apply[p].CAS((_L, _L), (REG, s')) in line [2j p' could not have aborted while busy-waiting on line El 
and thus p' aborted while busy- waiting in line [7J or [T4l Then p' executed line El and set its local 
variable p' .flag to true, and thus p could not have returned _L from line [18] during abort p (). 
Then p' returned _L in line 133"! and thus p' executed operations apply[p].CAS ((REG, s'),(PRO, s')) 
(in line [T9|) . and apply[p].CAS((PRO, s'),(_L, _L)) (in line 132]) . Since, apply[p] can be changed from 
(REG,s') only to (PRO, s'), and from (PRO, s') only to (_L,_L), it then follows that p 1 executes a 
successful apply \p\. CAS ( (PRO, s'),(_L, _L)) (in line [32]) . Then p' eventually resets apply[p] during its 
lockpO call. Since apply[p] ^ (_L, _L) throughout and p' completed its call to lock p () 

during [^p,^ - ], we have a contradiction. 

Case 2 - p"s call to lock p () returned a non-_L value. Then from the code structure p' executed 
operations apply[p].CAS ((REG, s'),(PRO, s')) (in line[16]or line I19H before returning from its call to 
lockpQ. Since apply[p] can be changed from (REG,s') only to (PRO,s'), and from (PRO,s') only 
to (_L, _L) and only by a process with pseudo-ID p, it then follows that apply[p] = (PRO,s') when 
p n s lockpO returns. Then it also follows that apply[p] = (PRO,s ; ) until a process with pseudo-ID 
p executes an apply[p].CAS ((PRO, s'),(_L, _L)) operation. 

Since p' won the lock L, it follows that some process, say r, eventually executes a call to 
release p (j), for some integer j. Since a call to release p (j) is wait-free and all processes continue 
to take steps, it follows that eventually r executes lines 148 1 and 149 1 where it reads value (PRO, s') from 
apply[p] in line 08] and resets apply[p] with a apply[p].CAS((PRO, s'),(_L, _L)) operation in line 09) 
Since p does not abort, and no other process calls lock p () concurrently, it then follows that 
eventually p executes a successful apply [p]. CAS ((_L, _L),(REG, s)) operation in line[21 Since applyfp] 
changed only once from (PRO, s') to (_L, _L) while p busy-waited in line El it follows that p incurs 
0(1) RMRs during the entire process. Then our claims follow immediately from Claims ID.32l fa]) 
and uTMip . □ 

Lemma D.34. The abort-way is wait- free. 

Proof. The abort-way is defined to be all steps taken by a process (say p) after it receives a signal 
to abort and breaks out of one of the busy-wait cycles of lines [21 [7] or Q31 After p breaks out of 
one of the busy- wait cycles of lines 12"! [71 or [T4l p executes a call to abort p (). If p's call to abort p () 
returns _L, then p's passage ends, or else p's lock p () returns non-_L value and p calls release p () 
and p 7 s passage ends when the release p () method returns. Since abort p () and release p () are 
both wait-free (by Lemma lD.2j) . our claim follows. □ 

Lemma D.35. The starvation freedom property holds during history H . 

Proof. Consider a process p that begins to execute its passage. From Lemma [D . 33 f faj) . it follows that 
if p does not abort during lock p () and all processes continue to take steps then p eventually returns 
from lock p () with a non-_L value. Then p eventually calls release p (), and since release p () is 
wait-free, p eventually completes its passage. If p receives a signal to abort during lock p (), then p 
executes its abort- way. Since the abort- way is wait-free (by Lemma ID.34j) . p eventually completes 
its passage. □ 

Lemma D.36. If a call to release p (j) returns true, then there exists a concurrent call to lock() 
that eventually returns j. 

Proof. The only operations that write a value to Syncl are Syncl.CAS (_L, oo) in line [26l and 
Syncl.CAS (_!_, j) in line [37J From Claim ID.15[ Syncl is written to only by a releaser of L. From 
Claim ID.29I it follows that at Iq , Syncl = Sync2 = _L and PawnSet is candidate-empty, and 
R(I~) = 0. Then from Claims ID^37 la1 . ID~23l lfl) . [D~25T lal) . ID~257 le1 . ID~28tlB . and [D~28HIj l. the only 
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releasers of L during a Ctr-cycle interval T, are {JC, Q,Vi, . . . ,Ve}. Then from an inspection of 
Figures El El [10l [HJ H5] and HU it follows that only fC and Q can write to Syncl during Ctr-cycle 
interval T. 

Since p returns true, it then follows from an inspection of the code that p executed a successful 
Syncl. CAS(_L,j) operation in line I37| and thus failed the Ctr.CAS(l,0) operation in line 1361 and 
Ro\e[p] = KING at Jpl Then p = K for some Ctr-cycle interval T. Since /C failed the Ctr.CAS(l,0) 
operation in line [36l it then follows that Ctr was increased to 1 by process Q during T, and 
I2 = i§ < ij^. Since Jj~ = Jj^J and < ijT, it then follows that Q's lockgO call is concurrent to 
/C's release^Cj) call. 

From Claim ID.29I it follows that at Iq, Syncl = Sync2 = _L and PawnSet is candidate-empty, 
and R(Iq) = 0- Then from Claim lD.25l f[aj). Syncl = _L at and K, and Q are the only two 
releasers of L during [1%, A), where A is the first point in time when T is changed to a non-_L value, 
and A = min(ip,ip. 

Now, Syncl is reset only in line [58l and since Jj^p > Jj^S > A and J§p > > A, it then 
follows that JC and Q do not reset Syncl during [1% , A]. Since K, and Q are the only processes with 
write-access to Syncl, Syncl is not reset during [i^,A]. 

Consider Q's lockQ call (see Figure [T0|) . Since K, executed a successful Syncl. CAS(_L, j) oper- 
ation and Syncl is not reset during [7^, A], it then follows that if Q executes the Syncl.CAS(_L, 00) 
operation in line [26l then the operation fails. From an inspection of Figure [TUl Q either returns 
from its lockQ call in line [17] or line[27l In both these lines, Q returns the non-_L value stored in 
Syncl. Since K, is the only process apart from Q that can write to Syncl Q returns the value j 
that fC wrote during its release^Cj) call. □ 

Now consider an implementation of object ALock Arrays, where instance PawnSet is implemented 
using object SFMSUnivConst(AbortableProArray„), and the operations in lines 1551 ETJE51IM1 and 1571 
are executed using the doFastQ method, while the operation in line [21] is executed using the 
doSlowO . 



Claim D.37. Lines \64$65l \6T\ of doPromote () , all lines of doCollect () , and lines 57\62\ are not 

executed concurrently. 

Proof. From Claim ID. 13tfb] ) . it follows that only a releaser of L can execute any of these lines. 
From Claim ID. 291 it follows that at Iq , Syncl = Sync2 = _L and PawnSet is candidate-empty, and 
R(I Q ) = 0. Then from Claims iD^M a]) . . Hl25l jajl . IH25te jl . ITl28tlk] l . and ITX281H it follows 

that L has more than one releaser only during A) for some Ctr-cycle interval T. More specifically, 
there are two releasers of L only during A), and the releasers are fC and Q. From Claim lD.25lfk"| ) 
it follows that a doCollect () is executed only by /C or Q but not both. Then it follows immediately 
that lines of doCollect () are not executed concurrently. Since A = min 

nr> > [t follows from 

an inspection of Figures \8[ l9l [W\ [TTI and the code, that processes fC and Q have not executed a call 
to doPromote () or lines 1571(621 of helpRelease C) . before Vjp* and Vrr* respectively. Then none of 
the lines chosen in the claim are executed concurrently, and thus our claim holds. □ 

Lemma D. 38. (a) Both helpRelease^ () and doPromote p () have 0(1) RMR complexity. 

(b) doCollectpQ has 0(n) RMR complexity. 

(c) abortpO has 0(n) RMR complexity. 

(d) If a call to release p (j) returns true, then p incurs 0(n) RMRs during release^ (j) . 
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(e) If a call to release p (j) returns false, then p incurs 0(1) RMRs during release p (j) . 

Proof. Proof of (jaj) and ([b]): As per the properties of object SFMSUniv- 

Const(AbortableProArray n ) (Lemma I2.2p . an operation performed using the doFastO method has 
0(1) RMR complexity, as long as it is not executed concurrently with another doFastO method 
call. Since PawnSet is an instance of object SFMSUnivConst(AbortableProArray n ), where operations 
in lines l55l EH [65l [Ml and [671 are executed using the doFastO method, and each of these opera- 
tions are not executed concurrently (by Claim (ID.37|) ). it then follows that all of these operations 
have 0(1) RMR complexity. Then Part (jaj) follows immediately from an inspection of methods 
helpRelease () and doPromote () . Since method doCollectO has a loop of size n that incurs a 
constant number of RMRs in each iteration, Part (jbj) follows. 

Proof of (jej), @) and (jej): As per the properties of object SFMSUniv- 

Const(AbortableProArray n ) (Lemma 12. 2p . an operation performed using the doSlowO method has 
0(n) RMR complexity, where n is the maximum number of processes that can access the object 
concurrently. Since the operation in line 1211 is executed using the doSlowO method, the operation 
has 0(n) RMR complexity. Since helpRelease () and doPromote () have an RMR complexity 
of 0(1) (by Part ((aj)), and doCollectO has an RMR complexity of 0(n) (by Part ©), it then 
follows from an inspection of abort (), that a call to abort () has an RMR complexity of 0{n). 
Thus Part (jb]) follows. 

If a call to release p (j) returns true, then p does execute a call to doCollect p () in line I38j 
else it does not. Then from an inspection of release p (j) , Parts (jdj) and (jej) follow immediately. □ 

Lemma O follows from Lemmas [HJ ILTM ILTM HTM ILTM HTM and HTM 

E The Tree Based Randomized Abortable Lock 
E.l Implementation / Low Level Description 

We assume that the tree structure T provides a function getNode () , such that, for a leaf node leaf 
and integer £, the function getNode (leaf , £) returns a pair (u, i), where u is the £-th node on the 
path from leaf to the root node, and i is the index of the child node of u that lies on the path. 

We now describe the implementation of the abortable lock (see Figure fT7[) . 

Description of the lock p () method. Suppose process p executes a call to lock p (). With 
every iteration of the while-loop, process p captures at least one node on its path from leaf p to 
T.root. Suppose p executes an iteration of while-loop (lines 111 1101) and £ p = k at line [1] for some 
arbitrary integer k. In lineO process p determines the k-th node (say u) on path p and the index 
(say r) of it's child node that lies on path p , and stores them in local variables v p and i p . The 
variables v p and i p are unchanged during the rest of the iteration. In line El process p attempts to 
capture u.L, and thus node u by executing a call to u.L.lockO with pseudo-ID r. Ifp's ii.L.lock r () 
returns an integer value (say j) then p has been transferred all nodes on its path up to height j 
(we ensure j > h u ). If p's u.L.lockO returns oo then p has captured lock u.L. In lines H] and p 
stores the height of the highest captured node in its local variable £ p . In line[6l p checks whether it 
has received a signal to abort. In this case p releases all its captured nodes by executing a call to 
release p () in line [7] and then returns from its call to lock p () in line [8] with value _L. Otherwise 
p continues its while-loop. On completing its while-loop, p owns the root node, and thus returns 
with value oo in line [11] to indicate a successful lock() call. 

Description of the release p () method. Suppose process p executes a call to release p (). 
Let s be the highest node p owns at the beginning of release p (). We later prove that b s = £ p . 
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Algorithm: Implementation of the abortable lock 



define Node: struct { L: ALockArray A } 

shared: T: complete A-ary tree of height A and node type Node 

local: v: Node init _L; i,£, k: int init 0; abort signal: boolean init false; 



define function T.getNode (Node leaf, int £): returns a pair (u,i), where u is the £-th 
node on the path from leaf to the root node of T, and i is the index of the child node of 
u that lies on the path. 



Method lockpQ 



1 while £ < T .height do 

2 (v, i) <- T.getNode (leaf p , I + 1) 

3 vol <— u.L.lockjO 

4 if vol = oo then £ ^— £ + 1 

5 if val £ {_L,oo} then £ val 

6 if abortsignal = true then 

7 release p () 

8 return _L 

9 end 

10 end 

11 return oo 



Method release„() 



12 while k < £ do 



13 
14 



15 



(v,i) T.getNode (leafp, A;) 
if v. L. release^) then 
break 

k <r- k + 1 



16 end 



Figure 17: Implementation of the abortable lock 
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During an iteration of the while-loop (lines [T2]|16p . process p either releases a node on its path from 
leafp to s, or p hands over all remaining nodes that it owns to some process. 

Consider the execution of an iteration of the while-loop where k p = t at line [12] for some integer 
t < h s . In lineCEl process p determines the t-th node (say u) on path p and the index (say r) of 
it's child node that lies on path p , and stores them in local variables v p and i p . In line 1141 process 
p releases u.L, and thus node u, by executing a call to u. L. release (h s ) with pseudo-ID r. If p's 
u. L. release,. (h s ) returns false then p has successfully released lock n.L, and thus node u. If p's 
it. L. release,. (h s ) returns true then p has successfully handed over all nodes from u to s on path p 
to some process that is executing a concurrent call to u.L.lock(). If p has handed over all its 
nodes, then p breaks out of the while-loop in line I14j. and returns from its call to release p () . If p 
has not handed over all its nodes then p increases k p in line [15] and continues its while-loop. 

Notice that our strategy to release node locks is to climb up the tree until all node locks are 
released or a hand over of remaining locks is made. Climbing up the tree is necessary (as opposed 
to climbing down) in order to hand over node locks to a process, say q, such that the handed over 
nodes lie on path ? . There is however a side effect of this strategy which is as follows: Suppose p 
owns nodes v and u on path p such that (u,i) = getNode (leaf p ,h u ) and v is the i-th child on node 
u. Now suppose p releases lock v.L at node v. Since the lock at node v is now released, some 
process r ^ p may now capture lock v.L and then proceed to call u.L.lockj () . If process p has not 
yet released u.L by completing its call to u.L.releasej () , then we have a situation where a call to 
u.L.lock,() is made before a call to u.L.release^ () is completed. Since there can be at most one 
owner of lock v.L there can be at most one such call to u.L.lockjO concurrent to u.L.release^ () . 
This is precisely the reason why we designed object ALockArray n to be accessed by at most n + 1 
processes concurrently. 

E.2 Analysis and Proofs of Correctness 

In this section, we formally prove all properties of our abortable lock for the CC model. We first, 
establish the safety conditions on the usage of the object. 

Condition E.l. (a) If process p executes a successful lock p () call, then process p eventually ex- 
ecutes a release p () call. 

(b) A process calls method release O if and only if its last access of the lock object was a successful 
lock() call. 

(c) Methods lock p () and release p () are called only by process p, where p £ {0, . . . , N — 1}. 

(d) For every release^O call, there must exist a unique successful lock p () call that has been 
executed. 

Notations and Definitions. Let H be an arbitrary history of an algorithm that accesses an 
instance L of our abortable lock where Condition IE. II is satisfied. Consider an arbitrary node u on 
the tree T. Let h n denote the height of node u. 

A node u is said to be handed over from process p to process q, when p executes a v.L. release (j) 
call that returns true, where j > h u > b v and q executes a concurrent u.L.lockO call that returns 
j. Process p is said to start to own node u when p captures u.L or when it is handed over node u 
from the previous owner of node u. Process p ceases to own node u when p releases u.L, or when 
p hands over node u to some other process. 

Claim E.2. Consider an arbitrary process p and some node u on path p . 
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(a) If p executes a u.L. lockQ operation that returns value j £ {-L,oo}, then j > h u . 

(b) The value of £ p is increased every time p writes to it. 

(c) If £ p = k, then process p owns all nodes on path up to height k. 

Proof. Proof of (jaj) : Then from the properties of object ALockArray^ (Lemma 13 . X [> . it fol- 
lows that some process (say q) executed a concurrent u. L. release (j) operation. Then from the 
code structure, q executed a u. L. release (j) in line [T4l where £ q = j. Then q also executed a 
7~.getNode (leaf g , k) operation in line [13] that returned (u,i), for some i, such that h u = k q (from 
the semantics of the getNodeQ method). Since j = £ q > k q = b u , our claim follows. 

Proof of ([b]): Process p writes to its local variable £ v only in lines [Hand [5] Clearly, p increases 
£ p every time it executes line [H Now, suppose p executes line where it writes the value of val p to 
£ p , where v p = u, for some node u. Since p satisfies the if-condition of line [5] and the ALockArray A 
method lockQ only returns a value in {_L, oo} U N, it follows that p's call to u.L. lockQ returned 
a non-{_L,oo} value. Then from Part (jaj), val p > h u . Since p also executed a T.getNode (leaf p , 6) 
operation in line[2l where b = £ p + 1 that returned (u,i), for some i, such that b u = b (from the 
semantics of the getNodeQ method), it follows that val p > h u = £ p + 1. Then, p increases £ p when 
p writes val p to £ p in line [5j 

Proof of (jcj): Let t % be the point in time such that p writes to its local variable £ p for the z-th 
time. We prove our claim by induction over i 

Basis (i = 0) : Since the initial value of £ p is and £ p is written to for the first time only at 
t 1 > t°, the claim holds. 

Induction step (i > 0): Let the value of £ p be j after the {i — l)-th write to it. Then from 
the induction hypothesis, p owns all nodes on path p up to height j. Consider the iteration of the 
while-loop during which p writes to £ p for the i-th time, and specifically the T.getNode (leaf p , £ + 1) 
operation in line El Since £ p = j, at the beginning of this while-loop iteration, it follows from the 
semantics of the getNodeQ operation, that the operation returned the pair (u, i), for some i, where 
b u = j + 1. Now, process p writes to its local variable £ p only in lines [H and G3 

Case a - p writes to £ p in line [H Then p increased £ p from j to j + 1 in line [H Then, to 
prove our claim we need to show that p owns the node with height j + 1 on path . Since p satisfies 
the if-condition of lined! it follows from the code structure that p's u.L.lockQ method in line [3] 
returned the special value oo, where v p = u. Since h u = j + 1, and p successfully captured lock u.L, 
it follows that p owns the j + 1-th node on path p . 

Case b - p writes to £ p in line[H Let val p = x when p writes to £ p in line[5j From Part fb]), it 
follows that £ p is increased every time it is written to, and therefore val p = x > £ p when p writes 
to £ p in line [5j Thus, to prove our claim we need to show that p owns all nodes on path p with 
heights in the range {j, . . . ,x}. Since p satisfies the if-condition of line [5] and the ALockArray^ 
method lockQ only returns a value in {_L, oo} U N, it follows that p's call to u.L.lockQ returned 
a non-{_L,oo} value. Thus, p has captured u.L and now owns node u. It also follows that p has 
been handed over all nodes on path p with heights in the range {h u + 1, . . . , x}. Since h u = j, our 
claim follows. □ 

A process is said to attempt to capture node u if it executes a u.L.lockQ method in line El 

Claim E.3. (a) If two distinct processes p and q attempt to capture node v, then their local vari- 
ables i have different values. 

(b) A node has at most one owner at any point in time. 
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Proof. We prove our claims for all nodes of height at most h, by induction over integer h. 

Basis (h = 1) Consider an arbitrary node u of height 1, such that two distinct processes p 
and q attempt to capture node u. Then processes p and q executed a getNode ((leaf p , 1}) and 
getNode ((leafg, 1)) in lineEl and received pairs {u,i} and {u,j}, and set their local variables i p and 
i q to i and j respectively. Since p and q are distinct, leaf p and leaf g are distinct leaf nodes of tree 
T, and thus from the semantics of the getNodeO method it follows that i ^ j, and thus Part (jaj) 
follows. 

Consider an arbitrary node u of height 1. From Part (jaj), it follows that no two processes 
execute a concurrent call to u.L.lockjO for the same i, and thus it follows from the mutual 
exclusion property of object ALockArray^, that at most one process captures u.L. By definition, a 
process can become an owner of node u only if it captures u.L or if it is handed over node u from 
some other process q. If a node u is handed over from some other process q, then q also ceases to 
be the owner of node u at that point, and thus the number of owners of u does not increase upon 
a hand over. Thus it follows that node u has at most one owner at any point in time, and thus 
Part (jbj) follows. 

Induction Step (h > 1) Consider an arbitrary node u of height h, such that two distinct 
processes p and q attempt to capture node u. Then processes p and q executed a getNode ((leaf p , h)) 
and getNode((leaf 9 , h)) in line El and received pairs (u,i) and (u,j), and set their local variables 
i p and i q to i and j, respectively. For the purpose of a contradiction, assume i = j. From the 
semantics of getNodeO method, i = j only if the (h — l)-th nodes on path p and path ? are the 
same (say w). From the induction hypothesis of Part (jbj) for h — 1, w has at most one owner at 
any point in time. Since £ p = t q = h — 1 when p and q attempt to capture node u, it follows from 
Claim lFl2t jcj) . that p and q own all nodes up to height h — 1 on their individual paths path p and 
path^. Then p and q are both the owners of w — a contradiction. Thus, Part (jaj) follows. 

Since Part (jaj) holds for h, Part (jbj) holds for h, as argued in the Basis case. □ 

Lemma E.4. The mutual exclusion property is satisfied during history H . 

Proof. Assume two processes p and q are in their Critical Section at the same time, i.e., both 
processes returned a non-_L value from their last lock() call. Then both processes executed linefTTI 
and thus l v = £ q = T. height holds. Then from Claim IE.2l f[cj) it follows that both p and q own 
node T.root. But from Claim lFT3tjb|) . at most one process may own T.root at any point in time - 
a contradiction. □ 

Claim E.5. Process p repeats the while-loop in lock() at most A times. 

Proof. Consider an arbitrary process p that calls lock(). From the code structure of lock(), it 
follows that if p repeats an iteration of the while- loop then p either executed line H] or line [5] in its 
previous iteration. Then it follows from Claim IE.2ljb"|) that p increases £ v every time it repeats an 
iteration of the while- loop. Since the height of the T is A, our claim follows. □ 

Lemma E.6. No process starves in history H . 

Proof. Since no two processes execute a concurrent call to -u.L.lockjO for the same i (from 
Claim IE. 31 (jaj)), it follows from the starvation-freedom property of object ALockArray A , that a 
process does not starve during a call to u.L.lockO for some node u on its path. 

Consider an arbitrary process p that calls lock(). Since p repeats the while-loop in lock() at 
most A times before returning from line [11] (follows from Claim lEl)|) . it follows that p starves only 
if p starves during a call to n.L.lockO in line [3] for some node it. As already argued, this cannot 
happen, and thus our claim follows. □ 
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Lemma E.7. Process p incurs 0(A) RMRs during release p (). 

Proof. Consider p's call to release (). Since i v < T. height = A, it follows from an inspection 
of the code that during release (), p executes at most A calls to L release () (in line 1 14[) . and 
at most one of the LreleaseQ calls returns true. As per the properties of object ALockArray^ 
(Lemma 13. ip . a process incurs 0(A) RMRs during a call to L.releaseO, if the call returns true, 
otherwise 0(1) RMRs. Then our claim follows immediately. □ 

Lemma E.8. Process p incurs 0(A) RMRs in expectation during lock p (). 

Proof. A process may or may not receive a signal to abort during lock p O- 

Case a - p does not receive a signal to abort during lock p O- As per the properties of object 
ALockArray A (Lemma 13. ip . if a process does not receive a signal to abort during a call to L.lockO , 
then the process incurs 0(1) RMRs in expectation during the call. Since p repeats the while-loop 
in lock() at most A times (by Claim |E75|) . and p does not receive a signal to abort during lock p O , 
it follows that p incurs 0(A) RMRs in expectation during lock p O- 

Case b - p receives a signal to abort during lock p (). As per the properties of object 
ALockArray^ (Theorem 13. ip . if a process aborts during a call to L.lockO, then the process in- 
curs 0(A) RMRs in expectation during the call. Since p repeats the while-loop in lock() at most 
A times (by Claim lE5l) . and p executes at most one call to u. L.lockO after having received an 
abort signal, it follows that p incurs 0(A) RMRs in expectation during lock p (). □ 

Lemma E.9. Method release () is wait- free. 

Proof. As per the bounded exit property of object ALockArray^, method release () of the object 
is wait-free. Then our claim follows immediately from an inspection of the code of release () . □ 

Lemma E.10. The abort-way is wait-free and has 0(A) RMR complexity. 

Proof. The abort-way of a process p consists of the steps executed by the process after receiving a 
signal to abort and before completing its passage. From Lemma IE. 91 and lE.7l method release p () 
is wait-free, and has 0(A) RMR complexity. From Claim IE51 a process repeats the while-loop in 
lock p () at most A times. Then from an inspection of the code it follows that a process executes 
all steps during its passage in a wait-free manner, except the call to u. L.lockO in line El and that 
a process incurs at most 0(A) RMRs during all these steps. 

To complete our proof we now show that if a process has received a signal to abort and it 
executes a call to u. L.lockO in lineEl for some node u, then the process executes u. L.lockO in 
a wait-free manner and incurs 0(A) RMR during the call, and does not call v. L.lockO for any 
other node v. 

Suppose that p has received a signal to abort, and p executes a call to u. L.lockO call in lineEl 
Since p has received a signal to abort, it follows that p executes the abort- way of the node lock 
u.L. As per the properties of object ALockArray^ (Lemma 13. ip . its abort-way is wait-free and has 
0(A) RMR complexity. Then p executes the u. L.lockO call in line [3] in a wait-free manner and 
incurs 0(A) RMR complexity. It then goes on to satisfy the if-condition of line[6l and executes a 
call to release () in line [7] and returns _L in line El thereby completing its abort-way. Thus, our 
claim holds. □ 

Theorem O follows from Lemmas MM EH EH EH ES and lETTOl 



63 



F Remaining Proofs of Properties of ALockArray n 

Claim F.l. Suppose a process p executes a call to lock p () during a passage. The value of Role[p] 
at various times is as follows. 



Points in time 


Value of Role[p] 


f 


{oo, KING, QUEEN, PAWN} 




PAWN 




PAWN.P 


m- 


{KING, QUEEN, PAWN.P} 




QUEEN 




{KING, QUEEN, PAWN.P} 



Proof. Since the values returned by a Ctr.incO operation are in {oo, 0,1,2} = 
{oo, KING, QUEEN, PAWN}, Rolefp] is set to one of these values in line [5j Hence, 
Rolefp] € {oo, KING, QUEEN, PAWN} at Jp. If p satisfies the if-condition of line El then 
Rolejp] = PAWN, and p changes Role[p] next only in line O Hence, Role[p] = PAWN during 
[c?, JP|. In line [9] p changes Role[p] to PAWN_P and does not change Role[p] thereafter. Hence, 
Ro\e[p] = PAWN.P at f . 

Process p does not change Role[p] after line [H To break out of the getLock loop, 
Ro\e[p] e {KING, QUEEN, PAWN_P| must be satisfied when p executes line [U Hence, Ro\e[p] = 
{KING, QUEEN, PAWN.P} during [^,^\- Since p executes line[I3]only after breaking out of the 
getLock loop, Role[p] G {KING, QUEEN, PAWN.P} at If p satisfies the if-condition of line [HI 

then Role[p] = QUEEN, and since p does not change Role[p] thereafter, Role[p] = QUEEN at fl^. □ 

Claim F.2. Suppose a process p executes a call to abort p () . The value of Ro\e[p] at various points 
in time is as follows. 



Points in time 


Value of Role[p] 


l L V J V J 


{QUEEN, PAWN} 





PAWN 


Mm 

V°v i v J 


PAWN.P 




QUEEN 



Proof. Process p calls abort p () only if p has received a signal to abort and p is busy waiting in 
one of lines [2l [71 or 1141 Then, the last line executed by p before calling abort p () is line El [7J or 
lined! From Claim EU it follows that Ro\e[p\ = PAWN at JJ, and Role[p] = QUEEN at ip. 

Now, p's local variable flag is set to value true for the first time in line [31 If p fails the 
if-condition of line [T8l then p must have executed line [3j and thus p broke out of the busy-wait 
loop of line [2J Then, p last executed line [7] or line [33] before calling abort p (). Hence, Role[p] £ 
{PAWN, QUEEN} in [^,^\, since p changes Role[p] next only in line[22j 

If p satisfies the if-condition of line 1201 then Role[p] = PAWN, and p changes Role[p] next only 
in line[22j Hence, Ro\e[p] = PAWN at i n line [221 P changes Role[p] to PAWN_P and p does 
not change Role[p] after that. Hence, Role[p] = PAWN_P during . If p does not satisfy the 

if-condition of line [23 then Role[p] = QUEEN at ff^,$P\ follows. □ 



Claim F.3. Suppose a process p executes a call to release p (j) during a passage. The value of 
Ro\e[p] at various points in time is as follows. 



64 



Points in time 


Value of Ro\e\p\ 




fL/IM/" HI ICCM DA\A/M Dl 

|r\INvj, yUbbN, rAWIxLr} 




KING 




QUEEN 


m- 


PAWN.P 




{KING, QUEEN, PAWN.P} 



Proof. Suppose the point in time ijpK Then, p is is executing a call to release p (j), and p 
last executed a call to lock p () that returned a non-_L value. Then, p's call to lock p () either 
returned from line [T7] in lock p () or from line [23] or line [27] in abort p (). From Claim IF.ll 
Ro\e[p] G {KING, QUEEN, PAWN.P} at time an d from ClaimQ Ro\e\p} = PAWN.P at inl- 
and Ro\e[p] = QUEEN at J23-. Therefore, Role[p] € {KING, QUEEN, PAWN.P} at time Jpk 

From Claim ID.4lfbj) . Role[p] is unchanged during release p (). Therefore, Role[p] G 
{KING, QUEEN, PAWN.P} during [f^Kf^ - ] and [JpKf^. Then, from the if-conditions of 
lines 1351 |4"2] and |4"5| it follows immediately that Ro\e[p] = KING during and Role[p] 

= QUEEN at §3-, and Role[p] = PAWN.P at §0". 

□ 

Claim F.4. Suppose a process p executes a call to doCollect p () , helpRelease () or 
doPromote p () during a passage. The value of Role[p] at various points in time is as follows. 



Points in time 


Value of Role[p] 




{KING, QUEEN} 


[$&- m 

l u V ' V J 


{KING, QUEEN} 




{KING, QUEEN, PAWN.P} 



Proof. From the code structure, p does not change Role[p] during doPromote () , doCollect p () and 
helpRelease () . 

From a code inspection, doCollect p () is called by p only in lines 1291 and 1381 From Claim lFT2l 
Role[p] = QUEEN at anc j from ClaimES Ro\e[p] = KING at JpK Since Ro\e[p] is unchanged 
during doCollect p () , it follows that Ro\e[p] G {KING, QUEEN} during [JphipJ. 

Now, suppose p executes a call helpRelease p () . From a code inspection, helpRelease p () is 

called by p only in lines EH E3 and H3 From Claim EH Role[p] = QUEEN at Jf^ and from 
Claim D Role[p] = KING at JjS" and Role[p] = QUEEN at . Since Role[p] is unchanged 

during helpRelease () , it follows that Role[p] G {KING, QUEEN} during [^f^ - ,^. 

Now, suppose p executes a call doPromote p () . From a code inspection, doPromote p () is called 
by p only in lines M\ and [U5] From Claim E3 Role[p] = PAWN_P at and fr om earlier in 

this claim, Role[p] G {KING, QUEEN} at JP^K Since Role[p] is unchanged during doPromoteQ, it 
follows that Ro\e\p] G {KING, QUEEN, PAWN.P} during $P~,$P\. □ 
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